How to demonstrate SQL injection? I've got lines in my PHP/MySQL code which look like this:

...
$sqlquery = "SELECT price FROM products WHERE 1=1 AND id=".$_POST['id'];
...
... query is executed
...
echo $price;

As a test/demonstration, how can I subvert this to show something like a user's password if I had a table users like:

id | username | password
------------------------
 1 |  abcde   | qwerty

Alternatively, what else can I get the system to show?

I'm assuming your using standard PHP mysql_query function in which case something like this would be effective in your example.

SELECT price FROM products WHERE 1=1 AND id=
999999999999999999999999
UNION ALL
(SELECT CONCAT(username, ' ', password) FROM user) limit 0, 1;

Explanation

Use an ID of a product that is not going to exist.
UNION with users table.
SELECT a single column in the users table to return, as your only returning a single column from the product. In this case returning a concatenated field of the username and password columns.
Limit by 1. As your code presumably expecting only a single result from query the query. You could alternatively use a WHERE condition to specify a specific user that you want to retrieve.

Another example would be to use group_concat this would allow for the retrieval of all the entries from the user table in a single query. Inspired from the answer on another question here.

SELECT price FROM products WHERE 1=1 AND id=-1
UNION ALL
(SELECT CONCAT(GROUP_CONCAT(username), '\n', GROUP_CONCAT(password)) FROM user);

Additional resources covering SQL Injection attacks:

SQL Injection from php manual
SQL Injection Cheat Sheet
SQL Injection Attacks by Example
xkcd: Exploits of a Mom


Safe to connect to external drive? A customer provided an external drive (USB 2.0 and Firewire 800 connections), and wants me to copy files onto the drive.  The drive is not new.  I have no particular reason to suspect the customer would intentionally send a drive containing malware, but I don't know that the drive is clean.

I'm using Mac OS 10.8.3; is there a significant risk of malware transfer upon connection?  Is there a safe way to inspect the drive before copying the files?

EDIT
For clarification, I'm concerned about the risk of triggering malware transfer from the USB drive to my computer upon connection.  This might be a real risk; I'm asking for confirmation that this transfer-upon-connection risk is real in this scenario, or imagined.

ANOTHER EDIT
@Adnan answered the question as stated, and I agree with his answer.  I now realize I was also interested in another possibility -- the device might mask its nature or purpose.  The USB page on Wikipedia states that USB 3.0 supports a guest device initiating communication with the host upon connection, and that Fireware has always had this capability, while earlier versions of the USB protocol enforce a "speak-when-spoken-to" behavior on guest devices.  An external drive is unlikely to initiate communication, but a malicious device might.  So if you trust that the device is just an external hard drive, connecting that drive to a Mac OS or Windows computer (with Autorun turned off) is probably not risky by itself.  But if the device is not just an external drive (i.e. it's something like the USB Rubber Ducky), there is some risk.

Respectfully, @Adnan is dead wrong in some key assumptions that it is relatively safe to open an unknown external drive.

As I answered here, it is not safe to connect any infected drive without proper safeguards in place.

In fact, the only way to be 99.99% (nothing in security is certain) sure it's malware-free is to actually do a forensic examination on it. At a bare minimum you should only attach an unknown external device using a proper VM. Ideally, you would take a forensic image of the drive and then examine it in the VM.

Note that you can do this 'safely' but only if precautions are followed.

Here is a simple article that outlines a few real-world examples.

Bear in mind that it is not just limited to autoplay features. There are sooooo many ways to hide things digitally and then execute them (leveraging OS/driver/buffer exploits for example).

Update: you may want to keep your ears peeled for more information on this as it's presented at Black Hat soon.


Password hashing for local servers I'm running a local web server on my Raspberry Pi and want to have a login screen. My plan is to hash the password and store the result in a text file ( This is where I'm storing settings for the result of the application ).
Is this the best way to go about it? I'm aware that if an attacker is able to find the hash then they can just make a request to the local server and get authorised that way so is there any point to the password at all?
The Pi will be turned into a Wireless Access Point for which a user would access the local server

Depending on the application you are using, you could enable libpam access and using the password stored on /etc/shadow for authorization, for example.
If this isn't possible or is too complex, you could salt and hash the password using Bcrypt, and saving both the salt and hash on the text file. Even if an attacker finds the file, he will not be able to login unless he can alter the file and add his own password to it.


Append or prepend a salt to a password? Does it matter how I add a salt to a password in my application: by appending it or by prepending?

# 1
res = sha256(salt + password)

# 2
res2 = sha256(password + salt)

I've been told that the 2nd option is better.

This scenario doesn't really apply to password storage, but more for trying to use a standard hash to validate user input.

The reason data+salt is better is because it makes it more difficult to perform a Length Extention Attack   The assumption here is that the user does not control the salt, but does control the data.  If the user can control the end of the input to a hash, he/she can control/predict what the hash will look like.  This link can give you a better idea of how length extention attacks work

Also, don't ever use sha256 to hash passwords.  Use some sort of Key Derivation Function, like BCrypt.


Proper storage/use of salted passwords? If a salt is not stored along with the hashed password in the database, is it possible that the password is salted?

I ask because in a system I am working on there is only a password column, but when I review the code it appears that whoever wrote this is attempting to salt the password.

From what I understood passwords/salts are supposed to be stored like below:

email         | password (hashed)        | salt (not hashed)
test@test.com | de898928393a893sfe7f98s7 | S#ne3

So when a user registered with their password ("froggy" in the example below) it would go something like this:

//Generate salt (S#ne3 for this example)
//encrypt ("froggy" + "S#ne3")
//Save encrypted pw + salt to database AND save unencrypted salt to database

Then when the user attempted to login with "froggy" it would go something like this:

//Query database for user's record.  Store this in curUser object
//Check to see if the following match: encrypt("froggy" + curUser.salt) == curUser.password

Does this sound right?  If I am right, is it safe to assume that passwords on this system are not salted?

Some password hashing function traditionally encode the salt and the hash output as a single string, so the salt is there, but does not appear in the database as a specific column. Most bcrypt libraries do that. This might be the case for your system.

Also, the salt might be implicit (e.g. computed as the concatenation of the user name and a row ID, or something like that).


Any risks of reading arbitrary emails in HTML format? Emails can be sent with email software (via corresponding setting of a parameter in the software) in HTML format instead of the normal text format. Are there any risks of reading arbitrary (malicious) emails in HTML format?

It depends; it is possible to include malicious code (e.g. JavaScript) in HTML e-mails, but all serious e-mail applications (be it web apps or desktop apps) will prevent this from running when you read it, and exclude them if you decide to save the e-mail as HTML. Good PDF readers will do the same with 'infected' PDFs, actually.

If you somehow intercept the raw e-mail body, save it as a HTML file, and open it in a browser, you run the same risks as opening a random link on the Internet.


Domain SSL encryption from client to DNS Server Im wondering why the domain name is not encrypted when a request do a DNS Server is made. As it seems this is the main weaknesses for internet users.
I came to this when i heard that in germany vodafone has blocked kinox.to from their customers.

The Question which came up is how can they determine which site you are trying to access if everything is encrypted?

And could we solve the USA net neutrality problem with just encrypting the domain name?

... why the domain name is not encrypted when a request do a DNS Server is made.

DNS is an old protocol which predates the massive use of encryption on the internet. It was designed at a time when the peers in the network were usually considered trusted or at least not malicious. There are actually alternatives which encrypt the names, like DNS over HTTPS, DNS over TLS or DNSCurve.

  And could we solve the USA net neutrality problem with just encrypting the domain name?

Net neutrality is more about preferring one kind of traffic against other kinds and less about blocking illegal content (which is usually explicitly allowed even with net neutrality). Even if you encrypt the domain name the source and target IP of the connection, the used ports and the traffic pattern  are still visible to the ISP and can be used for categorization of traffic. Also, the ISP might let preferred customers mark their traffic in a specific way so that it gets priority. Thus, hiding DNS from the ISP will not help much with net neutrality. It might help with privacy though, i.e. making it harder for the ISP to use or sell behavior information about your internet usage.


Why is FREAK being presented as a brand-new vulnerability? If I understand correctly, FREAK refers to a "vulnerability" in which, when a client offers weak cipher suites (usually export-grade cipher suites with 40 or 56 bit encryption) and a server can accept those cipher suites, a man-in-the-middle can perform a downgrade attack to use one of those weak cipher suites, and then break them (through brute-force or other weaknesses). But is this really a new attack method? I thought downgrade attacks and the possibility to use them in this manner was already known for quite a while (and this is why TLS_FALLBACK_SCSV was created). Did it just now pop into the mainstream? Did some researchers decide to give it a "brand" name and present it as a new vulnerability (since many clients/servers still offer/accept those cipher suites)? Or is there something else behind it that's not mentioned in the news? Also, I would think major, modern browsers would not be configured to offer those weak cipher suites, or at least wouldn't use them without big warnings like with invalid certificates. Did browser developers really make such an oversight?

No. TLS_FALLBACK_SCSV was designed to prevent protocol degradation (from TLSv1 to SSLv3 for example), not cipher degradations.

To mitigate against cipher degradations, the server needs to stop offer export ciphers, or the client needs to stop accepting export ciphers.

TLS_FALLBACK_SCSV is designed to fix the vulnerability of downgrades in the protocol (regardless of cipher used), because SSLv3 and prior protocols, do have vulnerabilitys that can be used regardless of cipher.

Preventing export ciphers in a client is cumbersome, because the client must support any legacy ciphers aswell for backwards compatibility. But you could check in about:config if there is possibility to disable export ciphers.

If you however is running a server, its very possible to prevent the server from offering export ciphers at all, by reconfiguring it to never offer export ciphers in the SSL configuration. Then any cipher downgrade attacks cannot happen.

Note that you still need to support TLS_FALLBACK_SCSV, since a protocol downgrade can still break a "strong" cipher due to vulnerabilitys in the implementation.


Communication between two open endpoints, is this secure enough? I'm building a (very simple) tool to communicate between two servers. I started by asking if there was a better alternative than making a home made scripts and we came to the conclusion that for starter, a home made script was enough. (On stack-overflow, but since the discussion only occured in the comments, the question was closed)

To set things clear, the project is to send request to a server (web app endpoint) from a web app (manager).

Since the endpoint is accessible from everyone, I implemented a verification system to be a bit more secure. I know that a secure system is something that is known from everyone (and not closed).

So here's what I do :

When the manager sends a request, it concatenate all the value of the parameters that will be POSTed, plus a token. Then it sha256 the resulting string and send this among the parameters as a checksum.

On the endpoint, I concatenate all the parameters (except the checksum) and add the secure token, do a sha256 and compare it with the checksum parameter. If they are the same, everything's good.

This ensure that the data submitted aren't modified (in case someone is listening the network), the data come from a trusted source (with the secure token that is normally only known from my apps).

The only risk I can see here, is if someone get the secure token. Then this protocol fails. But in the same idea, if someone gets my facebook password for instance, he will be able to post anything!

Is this enough ? Do I need to implement more steps. I thought about these ones, what do you thing :

Adding https in the endpoints
Verifying the source ip

Thank you

You are relying on "security through obscurity", and implementing this type of security is never a good idea.

You can create a vastly more secure and easier solution by implementing SSL (or TLS) on your solution. Here is a very good tutorial on Stunnel:

you install stunnel
create custom certificates
encrypt everything transparently

Using stunnel you can treat all data in clear text, without adding complexities like encryption, encoding or authentication.


On Gmail I received an Incoming TLS Encrypted Message. Will my reply be encrypted by default to different email provider? If I receive an incoming TLS encrypted message from another email provider like outlook/hotmail, will my reply in transit from gmail to outlook/hotmail be encrypted by default as well?

TLS transport security between federated servers is fairly common now, however this is not encrypted email.
Gmail does not support email encryption.The content of your email is NOT encrypted, nor the replies. The email content is in clear text on all the servers involved.


CLI application running user defined command periodically For a toy CLI application I'm writing, I'd like to store a string with an user defined command that will be executed periodically (like shell -c <command_string>).
I have seen other applications do this, for example in fzf you can set an environment variable with a command to be executed every time the application runs.
I'm worried about an attacker being able to modify this string with something malicious, but I don't know if my concern is justified: if the attacker is able to modify this string, maybe it already has access to the user's system.
The string with the command will be stored in a SQLite database along with other application data. (I'm aware that I have to take measures when I store the data to avoid SQL injection)

This boils down to a core question:

Is sh a valid command?

If so, then the user already has access; there is nothing further to contemplate in the question as-stated; a "malicious" user will have just as much access as a "non-malicious" and you should go to a regular threat model for potentially-malicious logged-in users, such as sandboxing.
If not, then you really ought to:

Set up a whitelist of permitted commands
Ensure you are sanitizing (or, better-yet, parameterizing) user input appropriately

example: if your toy CLI application is a Python program—
def handle_user_input(untrusted_string: str):
    user_command = shlex.split(untrusted_string) #: list
    if not user_command[0] in whitelist:
       raise ValueError("Non-whitelisted command.")
    store_command(user_command)

def event_callback(user_command: list):
    """Is called on the parameterized, whitelist-checked user_command list every interval"""
    assert isinstance(user_command, list)
    assert user_command[0] in whitelist
    subprocess.run(user_command)

Consider contingencies for when one of the whitelisted programs has a shell-execution vulnerability anyway, and this use-case reduces to what where sh is allowed (i.e.: sanbox the user.)

Your threat-model is poorly-defined in the question as-stated, but I hope this helps.

Also, check out this answer on another question — he expresses much better what I've tried to communicate here.
Allowing them to "run a command" is tantamount to letting them log in (after all, that's what "logging in" gates in the first place.)


Is it possible to verify that a signature was made prior to the content of the document it is found on? In What to do after I signed a blank sheet of paper given to me by my manager?, a distressed individual (B) has signed a blank piece of paper and given it to an adversary (A).

A  has openly stated to B that her intention is to use this paper to create a forgery, making it look like the contents have been signed in a normal fashion by B.

Imagine the worst case scenario where A does make the forgery, nobody believes B, and the case ends up in court. Using current forensic methods, could one prove that the contents of the letter were written to it later than the signature?

I know that one can date the age of various items, however, I am unsure if such methods are precise enough to be reliable here.

Does it matter if:

A writes the letter five minutes, one day, one month or one year after the signature was made?
The text on the document is written by laser printer, ink printer, typewriter, ballpoint pen, other pen, et cetera?

The answer to your question is yes, it is possible with inks to determine how long they have been set and perform a differential analysis to see how far apart the different inks were set. This may not be possible with all ink types, and the closer the attacker sets the ink after the initial signing will play a major factor. Another major factor will be the amount of time between the initial signing and the actual analysis.

The best case scenario for the attacker would be getting the signature, applying their forgery immediately, and then revealing as little about the document as possible. The longer they can retain the document and prevent the analysis, the better off they are. The inverse would be true for an analyst.


Is Certified | Ethical Hacker (C|EH) a scam or legitimate? I've been doing a lot of research on Certified | Ethical Hacker (C|EH) to see if it's a credible certification. But I've stumbled across a Wikipedia article on it and discovered that the sources are straight from the company EC-Council the ones that made the certification in the first place. The writing of the article sounds like it's marketing it to you. It didn't have a wiki article on EC-Council itself and the founder and CEO is from India (I'm not being racist or anything) I even signed up for it on the EC-Council website and got a message from the employee who is from India. Does anyone know the real history of the company or is it a scam?

Many people in the security industry do not think highly of EC-Council, the company behind the Certified Ethical Hacker (C|EH) certification. That doesn't mean that the ceritification itself is a scam, though.

In my experience, there are very few security certs that actually provide value. Sure, studying the topics that are covered on the exam can absolutely be helpful, and may improve your knowledge, but having certifications -- with the possible exception of the OSCP -- doesn't really show that you know much about security.

That said, it depends on why you're looking to get certified in the first place. If your primary goal is demonstrating to non-technical hiring managers that you're somewhat qualified to do security work -- or if the jobs you're applying to require security certifications -- then it can absolutely be valuable. If, however, you're trying to show a technical audience that you know your stuff, holding a CEH will not accomplish your goal.

As someone who hires security engineers at several different levels, I think of CEH on about the same level as Security+ -- that is to say, it's better than nothing, but not particularly impressive. It certainly won't get you a job, but frankly, neither will more well-known certs like the CISSP.

I hope this helps. If you find the material for CEH interesting, I'd say go ahead and take the exam. It might help get your resume in the door (HR screeners will probably like it), and if you think it looks silly, you're not required to keep it on your resume.

Good luck!


How to block I2P and Freenet to my network? I am trying to find a way to block I2P and Freenet darknets in a corporate network. Does anyone know a way to block them (on firewall)? Do I need to close particular ports or block entry nodes (like Tor)?

You won't have much luck. All of those are designed specifically to circumvent censorship. You may have very limited luck by simply downloading and keeping an up to date list of Freenet IPs and I2P IPs and blocking them, and an up to date list of Tor nodes with the "guard flag" and blocking them. This will not stop anyone for more than 5 minutes. Alternatively, you may be able to perform random searches of people who use more than a certain amount of traffic, if excessive traffic is a concern, or people who have a certain ratio of unexplained to regular traffic, and reprimand those who are caught using disallowed software, and write them up if they knew better.

The reason it'll be hard to block these software is:

Freenet can connect using random ports to people who are not identified in the Freenet network, called "darknet mode". It randomizes packet sizes and obfuscates the protocol to prevent detection.

Tor is even better at evading censorship. You say you just need to close ports or block certain IPs to block it, but that's not true. It can use bridges, which are unregistered Tor nodes that listen on random ports. They furthermore can obfuscate their traffic even better than Freenet can. This can range from simple encryption to traffic shaping to literally disguising traffic by encoding it as a stream of PDF files, or a stream of javascript/html, or a video stream in the Skype format, or even a stream of random dictionary words in plain text.

I know little about I2P, but I believe it can use similar traffic obfuscation technologies as Tor, as well as unlicensed entry nodes.

Note that both I2P and Freenet are self-contained networks. They cannot be used to access the outside internet, so there isn't a risk of them being used to browse Facebook or Pornhub secretly. I2P does have "outproxies", but I believe they are so few as to be almost useless. Freenet only works with internal Freesites and I2P only works with internal eepsites. Tor on the other hand works with both real websites and Tor-specific onion sites ("hidden services").

Lastly, please consider the reason you are trying to block these technologies. If you were asked to do so by your boss, or if it is taking up an excessive amount of traffic, it's totally understandable. But unless there are compelling reasons otherwise, privacy should be a valid reason to use such technologies.


Is SFTP going to improve Wordpress security? Disclosure: I am a developer and not a security expert

I am working on a Wordpress site for a client who is (understandably) concerned about WP security. The client will be hosting the site on their own infrastructure and their IT department that manages their servers is asking me to configure SFTP. This was raised when I gave the webserver (www-data) ownership over the WP site files.

One of the things that made me even question the benefit of SFTP was realising that you store the SFTP credentials and key details in the WP-config.php file.

The concern here, in my opinion, was that if there was a vulnerability that was exploited and the hacker managed to compromise the WP installation, they can obtain these SFTP credentials with a single line of code (file_get_contents (ABSPATH . "wp-config.php");)

So my questions is: If the server itself has no external FTP access due to their firewalls, what is the benefit of SFTP over FTP? I've read numerous nightmare issues with debugging SFTP errors with Wordpress so I'm reluctant to do so.

Um, I think your really confused about the technologies in use.
 you do not use FTP at all when using SFTP. Sftp is using an SSH connection between server and client and uses the sftp protocol for the file handling.
(so no ftp is being used at all).

SSH is a proven reliable and secure remote shell protocol that always multiple methodologies to not only encrypt but also to identify connections and user-sessions. You should always use a Public / Private key when using SSH for added security, but even without it SSH allready protects against MiTM and server-spoofing

(it 'knowns' the public key hash of the server after the initial connection and there for knowns when that is different and warns when that is the case).

this is all asuming you use SFTP to pull in an update.

When you push updates to your wordpress the whole security profile changes. SSH  by default stores your acces permsissions in a location athat is NOT accesable by your website (the users's home or the systtesms shadow file) Also you can setup your acces in such a way that the SFTP connection is 'jailed'.

This means that the 'shell' only has acces permissions to a very limited subset of the filesystem and to none of the systems file or tools outside what is configured.

The way you are describing 'SFTP' sounds like FTPS, or TLS+FTP. that would mean that there is a FTP deamon running on the server that also has TLS capabilities (just like a HTTP deamon would have to server HTTPS sites)

Even in that situation you could have additional security from using FTPS but it is a lot harder to configure, and has all the drawbacks of FTP.


How to use public key in ~/.ssh for asymmetrical encryption with OpenSSL I want to do an asymmetrical file encryption:

openssl genrsa -des3 -out private.key 4096
openssl rsa -in private.key -pubout -out public.key
openssl rsautl -encrypt -pubin -inkey public.key -in a -out b

But I already have a key pair in my ~/.ssh directory, so how do I use this instead of generating new keys? Simply switching filenames gives an error:

$ openssl rsautl -encrypt -pubin -inkey ~/.ssh/id_rsa.pub -in a -out b
unable to load Public Key

public.key starts with BEGIN PUBLIC KEY while ~/.ssh/id_rsa.pub starts with ssh-rsa, so I figure it's some sort of format problem.

How can I generate a ~/.ssh key that openssl understands, or how can I instruct openssl to understand the keys I have in ~/.ssh?

That RSA key is for authentication, not for encryption!  You should not use authentication key pairs for encryption (if you literally mean extracting the ssh key to store encrypted data, rather than to share the keypair with an X509 certificate); because the public and private operations or RSA commute.  For example, if you use the same key for both:

encrypt = verify = public
decrypt = sign = private
public * private = private * public = 1

This sequence involving Alices signing and encryption key pair:

Bob to Alice:  "here is a secret message": secretMsg := message * public
Eve to Alice: "please sign this for me": secretMsg
Alice to Eve: "okey dokey": toEve: signed := secretMsg * private
Eve:

signed
secretMsg * private
(message * public) * private
message * (public * private)
message * 1
message

Eve got the plaintext of a message that was sent encrypted to Alice.  It is not exactly this simple because of formats; but it is well known that keypairs are either for signing/identity or for encryption, but should not be used for both uses.


Background checking company requesting sensitive documents via email In the UK it is standard for IT workers in financial services to have background checks before starting a role.

It is also now normal for these background checks to be outsourced to a "specialist" company.  There are only two or three companies that do this checking in the UK that I know of.

This would all be fine, but I find one (dominant) company in particular insists on requesting sensitive documents being sent to them via email, including:

A passport scan
Scan of a recent utility bill or council tax bill with full address
Scans of a recent bank statement

Now this is not the sort of information that I would ever like to send via email.

What is the best way to deal with this situation, especially when dealing with a large employer and anonymous HR department.  There is always a veiled threat that non-compliance with their request will result in the position being lost.

First thought that comes to mind is whether it is even legal to require all those documents. Passport makes sense (what happens if you don't have a current passport?), but demanding bank statements is a bit skeezy. Common, but skeezy (just because many companies insist on something, doesn't make it legal). That said, this is an issue to ask a local lawyer, as these things are different between countries.

Furthermore, even if it is legal, the question is are you comfortable sending these documents to them (especially bills and statements). In my opinion, you should never agree to this type of thing - however, if you are committed to getting this job, you might have to comply with whatever they insist. You could still try discussing it with them - explain that you're not comfortable with it, and ask the employer (NOT the specialist company) if it is absolutely necessary (it usually isn't, but they ask anyway), and only if they still insist go along with it.

However, all the above is a Workplace.SE type of answer, not a SECURITY answer... so here are some options for you (assuming you want to be sending these documents to them):

Ask them for their public key (PGP or S/MIME, whatever your flavour) and simply send it to them encrypted;
Zip up all the documents and encrypt the archive, send them the password out of band (e.g. call and tell them verbally). Of course, strong passphrase, etc.
Ask if they have a secure service to upload files to, via their website / file safe / etc.

You should probably also ask for some assurance that your documents will be adequately protected once they've received the files (though don't be TOO optimistic about this being forthcoming (i.e. I doubt it)).


How are calls or SMS used to exploit a smartphone? How could a phone number be used as a means to gain access to a smartphone? I am reading claims that you could receive a call or SMS on your phone and an attacker can install their malware that way. Are methods like that possible? That seems a bit over the top to believe. What exactly are the methods used to install malware on a smartphone. I have a pretty elementary understanding of information security, any books or sites to read are appreciated.

I think you are talking about Stagefright(CVE-2015-3864, /exploits/39640). It resides in Stagefright, an Android code library that processes several widely used media formats. It affects all Android phones upto version 5.1. It was first reported by a researcher of the company Zimperium. The vulnerabilities are extremely dangerous and extremely rare. It allows the attacker to compromise the victims phone without the user even taking any action, no authentication is required, you just have to know your vitctim's phone number, Android showing you a preview on your unlock-screen is enough to trigger the exploit and thus allowing to execute arbitrary code while you sleep and the day after the SMS is deleted and your phone is still compromised without your knowing, The attacker does this by sending a crafted massage that contains the arbitrary code mostly in the form of a MP4-video, the crafted SMS is in the MMS format which was found to be very useful in this process of exploitation.


symetric encryption and signature asymetric key is normally used for signature for non repudiation.

But what if one uses EMV CAP in TDS mode as described here http://en.wikipedia.org/wiki/Chip_Authentication_Program ?

Is non repudation possible since the user uses a banking card he cannot pretend he didn't sign could he ?

This question is a bit unclear.

It is important to understand that non-repudiation is a complex subject that involves legal, social, and technical considerations.  Non-repudiation is not just a matter of algorithms.  You seem to think that use of public-key cryptography is sufficient for non-repudiation; this is far from the truth.

I suggest you read up on non-repudiation; the concept is much more complex than this question seems to appreciate.  In particular, there is not sufficient information here to determine whether the system you have in mind achieves non-repudiation to a reasonable degree.

Here are some readings on non-repudiation:

How to achieve non-repudiation? and my answer: digital signatures are not sufficient for non-repudiation.
What is the difference between authenticity and non-repudiation


Dangers of jpeg with attachment If anyone has any suggestions for tags, feel free to add them, seeing as i'm not yet familiar with the ones used on this site.

I was wondering what the dangers are of appending a file to an image.

If you are using windows you can type

copy /b aPicture.jpg + someFile.xy newPicture.jpg

I did this and are sharing these 2 files, one with a simple txt message and one with a winrar archive:

The first image has a txt file in it, the second a winrar archive.

When you open the images with notepad++ you can clearly see the attachments.

Now my question: How dangerous is this technique?

Consider you had a graphical process, let's assume it was a gui program or that old cracked copy of counterstrike 1.6 everybody has somewhere around.
If I would replace a texture in the game for example with a manipulated image, could I then exec code somehow?

It is possible to open the image directly with winrar, so I was wondering if one could exploit this for any purpose.

Has anybody ever made experience with this?Since I first heard about it ,and after reading "daemon" by Daniel Suarez I am very suspicous at videogames, especially when they are shared at Lan-Partys and the like.

What you describe is not "attachements on images" but these are polyglot files, i.e. files which get interpreted differently by different programs. For example if you combine a jpeg (at start) with a ZIP file (at end) the image program will deal with the image while the archive program with the ZIP file since processing of ZIP archives is done from the end but processing of jpeg is done from the start.

I don't know of any exploits against games, image viewer or similar this way but this technique can be used to bypass analysis since many antivirus products expect the file to be of exactly one type. Thus the main danger for the end user is that a file containing malware might not be properly handled by the antivirus and the malware did not get detected. But, you should not rely fully on antivirus anyway.


Securely store basic auth credentials in database I need to be able to communicate with a REST API Service and store the username/password pair in a database.

The client talks to the API from a server within our DMZ, but gets the credentials from a database outside of the DMZ within the network.   I would like to be able to make this more secure so that if the server was compromised it would be difficult to access the credentials.

What is the best approach for storing the credentials securely?
I can't use a salt & hashing mechanism because the API demands the username/password pair as plain-text and they control the authentication process.

Platform and languages in use:
Windows/.NET/C#

One Solution

Addressing only the issue surrounding securely storing credentials. There is always a risk as the decryption key will still have to be stored somewhere.

For example, you could use OpenSSL to encrypt a string of text and then have that stored in the database on the "Insecure" Server. You'd have to use a reversible encryption method for this also.

Such a task could be accomplished with a simple PHP Script:

openssl_encrypt(PLAINTEXT, ENCRYPTION_METHOD, KEY, OPENSSL_OPTIONS, INITIALIZATION_VECTOR)

So in context, for example. (Ensure that you also add 16 bytes of padding before encryption and remove 16 bytes of padding on decryption, this can be removed by specifying specific OpenSSL options, however for ease, you can just add and remove the padding. Plus, this can also act as a degree of obfuscation, to a certain extent, in this example, 16 '=' characters have been used. This can also depend hugely on how your OpenSSL installation is configured, however, from personal experience, I always do just to be safe. Call it a touch of 'salt' if you would..)

openssl_encrypt("================username:password", "aes-128-cbc", "StRoNGeNcrYptIOnKey", 0, "16ByteIV--Random")

Running the above would produce something similar to:

+VUYZEh3FII7HRvJ8Qm8glERsgfsSKG9tE8Zyr2EJLL+9VaF7+41q/MeL8R1++L1

You can then run the subsequent decryption:

openssl_decrypt("+VUYZEh3FII7HRvJ8Qm8glERsgfsSKG9tE8Zyr2EJLL+9VaF7+41q/MeL8R1++L1", "aes-128-cbc", "StRoNGeNcrYptIOnKey", 0, "16ByteIV--Random");

Producing:

================username:password

There are a vast array of Encryption Algorithms that can be used. There is also a article on PHP.net showing how this can be achieved, and also includes Linux CLI examples, should you wish to do this via bash scripts also.

BEAR IN MIND

You will still have to keep a plaintext copy of the encryption key on your device if this is an automated process, which may not be ideal, nor would it be recommended. There is nothing to stop you using this approach and storing the encrypted data on your external server, however just take a moment to weigh up the security implications of storing a password in plaintext on a server.

If you're feeling neurotic

You could even encrypt the credentials once with one algorithm and then re-encrypt the cipher text with another, completely different algorithm.

Up to you, depends how secure the data is, and how much CPU time/justification/etc you want to dedicate to this.

Short Story

You need a reversible encryption solution if you want to be able to recover plaintext from cipher text and vice-versa.


How exploitable is a QR code in a login system? I'm taking a CTF challenge on a web service. The goal is to gather the most information possible of a user. I have access to it's login and password, but password is expired and the account must be recovered by uploading a QR code to the website. No other file extensions besides JPEG are allowed for upload. Given that, I tried to generate a QR code with the provided login info, with no results. Please notice that my understanding on this matter is very bad. So I was wondering if exploiting a QR code would a good attack vector. But I'm starting to realize that might not be a practical/executable way. Am I going in the right direction?

Instead of uploading user info to QR code try to upload a malicious script to bypass the login. If you found the uploads directory, you can run your script and get more access.


What vulnerabilities are there for a website that does not use SSL for a login page (or any pages) I see many websites that do not implement SSL either when logging in or at all. I know that you can simply sniff traffic on those sites and therefore see the user/pass in plaintext but what other vulnerabilities are there?

Most of the insecure sites are obscure sites that probably do not have much traffic and to my knowledge, in order to sniff someone's password the attacker would have to be sniffing that network (eg a cafe) when the user logs in. I personally find that unlikely and so I'm wondering how severe is this vulnerability these days?

SSL/TLS provides confidentiality, integrity and trust. Trust being the most important one, giving the client assurance they are really communicating with the person they thought they were. In case of SSL/TLS; without trust there is no point in encrypting data. Anyone can pass itself of as the intended party, and you wouldn't be able to verify this.

The other way around doesn't work either, and allows for an attacker to listen in and change the data. The internet is just a bunch of networks connected to each other, and because you can only protect your LAN at best, we conciser the internet to be an insecure channel. Network interception is no science fiction, and happens on large scale (your ISP, telecom provider, governments, etc) without targeting you in specific.

  I personally find that unlikely and so I'm wondering how severe is this vulnerability these days?

The opposite is true. In the last few years demand for secure communications has never been this high, and this is no paranoia. You really should care about SSL/TLS, and use them whenever possible. Anything that send personal data back and forth should use SSL/TLS, although this isn't the case by far, unfortunately. But, if you are going to setup an SSL/TLS secure environment, do it the right way. It has been argued that wrong SSL deployments can cause more harm then do good. In information security there is no such thing as doing it half.


Why should you generate SSH keys on client devices? Most tutorials for setting up SSH recommend generating the keypair on a client machine. Why exactly is this?

Assuming your communication lines are not compromised, and you delete the private key from the server after acquiring it, is it safe to generate the keys on a remote host?

Because most guides are written for people who are not experienced and it is assumed to be safer (by reducing possibilities for mistake) to prevent the private keys from being transmitted/stored outside of the client on which they were generated. ssh-keygen command also automatically sets the limited permissions to the generated private key reducing the number of steps required.

Where you generate the keys and how you distribute them depends solely on the process (in the "management process"-sense). As long as you do not the compromise security by using an insecure generator or an insecure channel, the exact place where you generate the key pair does not matter. It might as well be a third machine.


How is cryptoshredding a "sole pragmatic option for data disposal in the cloud"? I'm studying for the CCSP exam and I think I'm missing something here...

In reviewing data destruction/disposal methods, I'm aware that an on-premise IT environment has several options:

Physical destruction of media and hardware
Degaussing
Overwriting
Cryptoshredding

The training material I'm using states:

  In the cloud, many of these options are unavailable or not feasible.
  Because the cloud provider, not the data owner, owns the hardware,
  physical destriction is usually out of the question.  Moreover,
  because of the difficulty of knowing the actual specific physical
  location(s) of the data at any given moment (or historically) it would
  be next to impossible to determine all the components and media that
  would need to be destroyed.  Likewise, for that same reason,
  overwriting is not a practical means of sanitizing data in the cloud.

  That leaves cryptoshreadding as the sole pragmatic option for data
  disposal in the cloud.

(emphasis mine).

I get the first paragraph but I'm confused on how cryptoshredding alone would help here.  Is the assumption that the data would have always been encrypted at rest from the very beginning?  If not, how would cryptoshredding help to remove remnants of data that was previously stored unencrypted?

Am I missing something here?

Without the additional context of the rest of your training materials, it's hard to say for sure -- I don't think there's a textbook definition of "cryptoshredding".  However, if we use the Wikipedia definition, we see:

  Crypto-shredding is the practice of 'deleting' data by deliberately deleting or overwriting the encryption keys.[1] This requires that the data have been encrypted.

Consequently, yes, this only works for data that is encrypted.  Cryptoshredding would not work for unencrypted data as there's no key to destroy.

  Is the assumption that the data would have always been encrypted at rest from the very beginning?

Yes.  This is a best practice for any sensitive data in a cloud service anyway.  Your cloud provider can replace hard drives, have machines go down, maintain their own backup lifecycle, etc., all outside of your control.

  If not, how would cryptoshredding help to remove remnants of data that was previously stored unencrypted?

Data is not "previously stored" in my mind.  It is stored, and you might make an encrypted copy of the data, but then you need to destroy the original -- and don't have cryptoshredding as an option, which leaves you with 0 options for cloud storage effective data destruction.  This is back to the idea of storing it encrypted from the get go.


Antivirus being disabled by unknown source or application I am running a laptop with Windows 10 and free avast antivirus installed for protection. I keep the antivirus up to date all the time.

A couple of months ago I noticed that sometimes my antivirus is being turned off and disabled without my information (see picture). On some occasions I get a pop up notification on my desktop saying and unknown application is attempting to disable your avast protection.

I scanned my system with both avast and Kaspersky security scan but no threats was found. Can anyone help me find the reason behind this and suggest a solution?

It's worth noting that scanning your system with an anti-malware/virus application does not guarantee the detection of a virus.

It is possible that you have installed what is known as a trojan. This is a piece of malware that is disguised as a regular program or application. So think, have you installed any software from untrusted sources recently? Including pirated software.

If your computer IS infected, then your safest bet is to completely wipe the machine and start over. I imagine to disable your anti-virus this malicious application must have administrator access on your machine, either through some exploit allowing for privilege escalation or through such privilege being granted to the application by the user.

As something of an afterthought, have you tried checking your windows defender settings? I am aware that in some cases in the past my windows defender has attempted to disable my third party anti-virus software and configure itself as the primary anti-virus solution.

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


How do I verify that an ssh public/private keypair go together, is it different for openssl and ssh-key generated keys? Generating a Private Key...

$ openssl genrsa -out ./oci_api_key.pem 2048

Generate a Public Key...from the private key:

I'm trying to generate a public key from a private key in PEM format (the Base64 of a DER) by running:

$ openssl rsa -pubout -in ./oci_api_key.pem -out ./oci_api_key_public.pem

Next I'd like to:

Verify they go together...by comparing their MODULUS...

Private Key Modulus:

$ openssl rsa -in ./oci_api_key.pem -noout -modulus
MODULUS=<long-hex-number>

Public Key Modulus (doesn't work):

$ openssl x509 -in ./oci_api_key_public.pem -noout -modulus

So what am I missing here?
    unable to load certificate
    140084471075264:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:691:Expecting: TRUSTED CERTIFICATE

But it doesn't appear to work.  My public key doesn't have the TRUSTED CERTIFICATE line in it instead it's -----BEGIN PUBLIC KEY-----

You need to add -pubin to your openssl rsa invocation to work with the public key:

$ openssl rsa -pubin -in ./oci_api_key_public.pem -noout -modulus


Is "Discoverability = low" an acceptable reason to reduce the risk of a vulnerability? The outdated DREAD risk model (wikipedia) lists Discoverability as a criteria for judging the severity of a vulnerability. The idea being that something which is not publicly known and you would be unlikely to discover without deep knowledge of the application in question does not need as much panic as, for example, something with a published CVE (assuming there are no publish attack prototypes, since that bleeds into the Exploitablility metric).

I notice that CVSS v3.0 has no metric for how likely the vulnerability is to be independently discovered.

Wikipedia has this to say:

  Discoverability debate

  Some security experts feel that including the "Discoverability" element as the last D rewards security through
  obscurity, so some organizations have either moved to a DREAD-D "DREAD
  minus D" scale (which omits Discoverability) or always assume that
  Discoverability is at its maximum rating.

So my question is basically: apart from the very obvious "security by obscurity is bad", what are the arguments for and against using Discoverability as part of a risk analysis?

Low discoverability doesn't necessarily mean "security by obscurity".  It could just mean that the vulnerability lies deep in a portion of functionality that's rarely ever investigated.  It could also mean that discovery would require a corner case so narrow that even the initial discovery was unlikely to have ever happened.  Such examples would be Dirty COW and Spectre/Meltdown, both of which took almost a decade to be noticed.

On the other hand, low discoverability shouldn't necessarily mean low priority.  If a vulnerability with low discoverability is reported, other factors should be taken into consideration - such as impact and ease of exploit - in determining an appropriate response.  In fact, such considerations are exactly why risk rating scores like DREAD and CVSS exist.  However, as discussed in the comments, "discoverability" may only have meaning in the context of a private disclosure.  If a vulnerability is already public, the discoverability is essentially 100% and no longer a relevant consideration.


Is it a security risk to maintain an application developed for a version of .NET prior to 4.0? I've had a request that we upgrade all our internally developed applications to .NET v4.0.

Needless to say, this is a massive chunk of work. Is using applications based on the .NET framework prior to v4.0 a genuine security issue?

No it's not a risk to run an earlier framework (except for 1.x), just make sure it's patched as described below.

All frameworks will get free security updates as described in Mainstream and Extended Support phase.  Each framework needs to have it's own service pack.  (scroll to bottom of that link)

To make things easier, .NET 3.5 SP1 is considered a core component of the Windows OS.  The standard Windows support guidance applies.  In particular:

.NET 1.0 is a security risk since no hotfixes have been produced since SP3 past July 14 2009
.NET 1.1 should be at SP1, though security hotfix support ends October 2013 unless you are running it on Server 2003 (security hotfix support for Server 2003 ends July 2015).
.NET 2.0 should be at SP2
.NET 3.0 should be at SP2
.NET 3.5 should be at SP1
.NET 4.0 will reach end of support on all OS on January 12, 2016
.NET 4.5 should be at 4.5.2.  Support expiration is based on the OS and the most recent service pack for that OS.  (e.g. Windows 7 SP1)

  What is the Security Update policy?

  Security updates will be available through the end of the Extended
  Support phase (five years of Mainstream Support plus five years of the
  Extended Support) at no additional cost for most products. Security
  updates will be posted on the Microsoft Update Web site during both
  the Mainstream and the Extended Support phase.

  Is the Extended Hotfix Support program required for customers to receive security updates?

  No. Any customer can report a security issue to Microsoft. Microsoft
  will review the issue. If a security update is created, it will be
  made available to customers as described earlier in this document.


How can salted passwords work if you don't "keep the salts in the system"? In this report on the recent ParkMobile breach, the article has this comment from the company:

“You are correct that bcrypt hashed and salted passwords were obtained,” Perkins said when asked about the screenshot in the database sales thread.
“Note, we do not keep the salt values in our system,” he said.

If the salts are not "in the system", how could a system match a user-entered password to their salted hashes?

In this report on the recent ParkMobile breach, the article has this comment from the company: “You are correct that bcrypt hashed and salted passwords were obtained... Note, we do not keep the salt values in our system...”

The article states that "spokesman" Jeff Perkins made this comment.
Per ParkMobile's website, Mr. Perkins's title is "Chief Marketing and Product Officer."
With all due respect to the marketing folks, Mr. Perkin's may not be completely up to speed on all the technical details of ParkMobile's password hashing, and may not be speaking with perfect precision. Therefore, one answer to your question might simply be that his statement is not technically correct.

If the salts are not "in the system", how could a system match a user-entered password to their salted hashes?

This is a reasonable question to ask, since typically one stores the salts along with the hashes for bcrypt. That is, typically, the format of the stored bcrypt output is:
$2b$[cost]$[22 character salt][31 character hash]

Therefore, typically, the salt would be stored in the same database as the hash.
Without seeing the actual data from the data breach it is hard to say for sure what is going on here.
One answer is just that Mr. Perkins is wrong. However, there are certainly other possibilities, such as:

By "salt" he actually means "pepper."
They separate the bcrypt outputs (for example at the "$" characters) and actually do store the hash in a different database than the salt. In this case they still need to store the salt, and maybe the "system" in the quote is the hash database rather than the salt database. Note that this possibility is complete speculation (and atypical bcrypt usage).


Can other customers on shared hosting see requests from/to my site? I installed a wiki on my shared webhosting (using Apache) account. This wiki is set to private (no read/edit/create rights for unauthorized users) and I'm the only one with an account.

The wiki inserts the wiki page title in the URL path, e.g. a page titled "Foobar" would have the URL example.com/wiki/Foobar.

I want to make sure three things:

no-one shall be able to see my wiki content
no-one shall be able to see if I created a certain wiki page
no-one shall be able to see which wiki URLs I visit

In other words: not only the pages contain sensitive content, also the URL path is sensitive.

When I logout and visit example.com/wiki/Foobar (existent) and example.com/wiki/FoobarNope (non-existent) I (1.) can't see any content and (2.) there is no difference in the error message for the existent and the non-existent page.

I use the Firefox add-on RefControl to block the Referer header when I click at links to external pages.

I use HTTPS to encrypt the content and the URL paths (so if I ever should visit my wiki from an untrusted network, no sniffer should be able to see which wiki pages I visit, right?).

Now the only thing I'm not sure about is: What can the other customers on the same shared host see?

Each customer has SSH access. Installation of software is allowed (as long as no root is required). Eveyone has access to /tmp. I can start top and see what processes the other customers use at the moment. And probably more … (I'm not that savvy with this).

May it be possible that other customers see GET requests for the whole server? (if it matters: every customer has an own subdomain, the HTTPS encryption is accomplished by the hosters' wildcard SSL certificate)

Maybe something gets saved to /tmp when I visit a page in my wiki? Cache?

Maybe there is a global (error) log?

Or anything else?

Since the potential attackers (the other customers on the share host) can see your processes (as well as you see theirs), your Wiki and what you do with it is protected from their inquisitive eyes by the Unix security model: roughly speaking, non-root users cannot impact each other, subject to the access rights on files, directories and devices. You thus should make sure that the directories containing your site have adequate access rights (use chmod to set them). Take care that the Web server itself must be able to access them.

I suppose that your Wiki software uses a database, probably MySQL. Such database system use their own authentication layer, and enforce their own separation of users. There again, see the database documentation to check whether user separation is properly applied.

Ultimately, your security model relies on the lack of local exploits allowing standard users (like you or other customers) to gain root access on the machine or pierce the user separation layer in the database. A look at this database will show that this postulate might be a bit ambitious. Local exploits happen quite a lot, mostly because it is quite harder to protect against them than against remote exploits (IT security practitioners like to say that "the attack surface for local users is very large") and also because many people just don't care about them (local exploits do not matter much when you do not have potentially hostile local users). As usual, this is a risk vs cost trade-off: if security is really important for you, you should rent a dedicated server, not a shared hosting.

A note on SSL and the URL: with HTTPS, the URL themselves go through the tunnel, hence are encrypted. However, external observer can see the length of the encrypted data records, and thus infer the length (in bytes) of the URL you visit on your Wiki. This slight leak may or may not be important to you; if it is, try to get these lengths identical for all pages.


In mobile, can "Early Media" be sent from the phone? Early Media, aka in-band information, is sent from the network to the calling phone in some circumstances, to provide alternative tones or extra information about the status of the call. In GSM this is available because of "Early Assignment" of the TCH. This early assignment is also possible in the called phone, but I have never heard/read of a use for it, besides the initial purpose of avoiding delays.

Now, question is, does assignment of the TCH implies the capability of receiving early media FROM the mic of the phone, before the actual start of the conversation? And if the capability exists, has it been used?  Perhaps in outgoing calls there were plans to offer *44, voice activated dialing, services and then it is a sort of legacy.

Of course the worst possible case is the inbound call: TCH and microphone open in the called phone without actual ringing of the signal (call, abort with silent notification and leave channel open until the timer expires, then call again).

I don't believe that this is possible, as a standard/recommendation, due to the separation of signaling from media circuits.  The process of answering a call is separated from the interconnection of the circuits, and the latter is only possible/feasible after the call-status of acknowledgement of an answered call is returned.

The ringing heard on the caller side isn't necessarily indicative of the call-progress as it can and is often first provided by the originating network (you've heard double ringing before?), and the custom ringtones/messages are from a in-network peripheral that the called device is unattached from other than by account configuration stored separately from the physical device.

However, as a customization, this is not really a challenge for a non-standard device to capture the audio from the microphone of the pre-ringing device and send it back through the network as MMS (SMS-core extension) content.


Is android's FDE secure from offline attacks? Android provides FDE, but it uses lockscreen pin, which is (at least in my case) fairly weak (like a 4-digit PIN). Does it mean that my FDE could be easily broken by offline attack?

Or maybe master key is stored on TPM and all the crypto is done there? In that case it could rate-limit trials or even shut down itself after certain number of those.

I found this piece on source.android.com (emphasis mine):

  The encrypted key is stored in the crypto metadata. Hardware backing is implemented by using Trusted Execution Environment’s (TEE) signing capability. Previously, we encrypted the master key with a key generated by applying scrypt to the user's password and the stored salt. In order to make the key resilient against off-box attacks, we extend this algorithm by signing the resultant key with a stored TEE key. The resultant signature is then turned into an appropriate length key by one more application of scrypt. This key is then used to encrypt and decrypt the master key. To store this key:

However they don't explain if this signing process is somehow rate-limited or protected by other means.

The important thing to keep in mind is that the actual encryption keys for the volume are stored in the Trusted Execution Environment (TEE) chip, which is designed to provide secure key storage. The goal of the device is to act as an encryption oracle: you give it some data, it encrypts or decrypts it, then gives you the result. This means that if you take the flash chip out and try to read it directly, you'll just get encrypted data.

By default, there's no direct authentication from the user to the TEE that protects against an attacker just asking to have the data decrypted. This is where adding a PIN or passphrase to your phone helps - it acts as an authentication mechanism to the TEE to ensure that you can't just ask to have data decrypted without "proving" who you are.

The key phrase around rate limiting is this:

  The resultant signature is then turned into an appropriate length key by one more application of scrypt.

The scrypt KDF is designed to be slow and sufficiently memory-hard to make it difficult to parallelise on common compute platforms (e.g. CUDA). Also notice that they said "one more application of scrypt"; the DEK is already transformed via scrypt, hence it is made infeasible to try to "crack" the DEK by deriving it repeatedly against candidate passwords.


Does Microsoft Remote Desktop require a VPN to be secured? I am connecting from my home Windows 7 machine to a hosted server Windows Server 2008 R2. I am connecting to it using Remote Desktop on a non-default port.
I am wondering if I should go to the effort of setting up a VPN connection for Remote Desktop Access with something like OpenVPN. I'm not a security professional, I just want to try and make the connection to my hosted server as reasonably secure as I can.

As often with security, the answer to that is "maybe". In theory, if setup right and if you're keeping your system up-to-date, RDP is actually quite secure. Possibly not the most secure system available but still it can be considered secure enough for most usage (and can be extended if necessary).

The first and most relevant issue you will encounter with RDP is the potential for DOS against your administrator account. This one is easy to understand: if you've setup a limit to the number of failed attempt to log on, someone can simply keep trying to access your account and keep it locked. On unix, you'd use fail2ban to prevent that from happening but there is no clear equivalent in windows (although there are plenty of solutions, from scripts to full-fledged commercial program that will do the same). Another simple solution is to limit the range of IP addresses that will be allowed to connect to RDP in the first place or force users to go through a VPN first. Another option is to use IPSec. Yet another (and better) solution is to add 2 factor authentication to your system: mandating the use of a smartcard for RDP connection makes the whole authentication process very secure, if a bit difficult to setup.

The second issue you're going to encounter is the security of the connection. If you've setup RDP correctly (i.e. you've setup a server certificate correctly, you're forcing network-level authentication and you're using RDP over TLS) , then there is little risk.

Adding a VPN layer on top of this wouldn't add much to the overall security. Assuming you where running it from another machine it would still be a worthy addition since it would improve the security in depth (because in order to compromise the final machine you'd have to break two systems instead of one) but if you're installing everything on the same system, you actually increasing the system's area of vulnerability by adding another potential way to exploit vulnerability.


What if I develop my own hash algorithm to create strong passwords from easy ones? I came up with this idea but I cant figure out if it's good or bad, maybe you can help. My goal is: I want to create extremely strong passwords for my main accounts (gmail, skype and so on). I want to have different passwords for all my accounts that are longer than 20 characters and that contains lower+upper case chars, numbers and special characters. What would you do to achieve that?

It's pretty impossibile to remember even one password like that so I came up with this idea: what if I develop a (simple and secret) hashing algorithm that transforms easy passwords (even 3 or 4 characters) into strong ones?

In that scenario I would only have to remember "dog" for my Gmail, "black" for Yahoo and so on. When you have to login, you just process your easy password in your handmade script that converts it, than you just copy-paste.

I think this method is great for some reasons:

if your hashing algo is irreversible and secret, there's no way to figure out the "easy passwords" by having (even a lot) of the strong passwords (anyway you must be really unlucky if someone managed to hack all your main accounts on gmail, forums, instant messaging and so on)

i just have to remember extremely easy words for all my accounts while my "final passwords" will be bulletproof for lots of years

if well made, an easy hashing algo can just be remembered and used on paper instead of making a script (that could be eventually stolen). the algorithm can be easy because you dont need an extremely good avalanche effect (you won't be making tens of thousands of passwords, maybe just 100 or 200 in a few years?

Even if a cracker managed to understand the formulas in your hashing algorithm, there are no public rainbow tables for your algorithm, and I highly doubt that your gmail account is so valuable that anyone would start making one. This method is meant only for everyday passwords, not for high risk situations where NSA is involved, and it is good because the algoritm is related only to YOUR passwords, because it's not a public one. MD5 is used by thousands of websites, that's why people started wasting time/money to crack it. My personal algo will be just mine, so noone will be interested to invest money to crack it

What's your opinion?

PS. sorry of my extremely bad english :)

Don't roll your own crypto.

It lulls you into a false sense of security, and may be detrimental if you publish it and other people start using it. A hashing algorithm's strength does not stem from the opacity of its design; on the contrary, it benefits from the thousand expert minds looking at it.

Your basic idea isn't without merit, though. But if you are going to use hashed words as passwords, you might as well go for a vetted hashing algorithm which is known to be difficult to reverse.

  Even if a cracker managed to understand the formulas in your hashing algorithm, there are no public rainbow tables for your algorithm

By the way, proper use of salts defeats this problem entirely for public algorithms!


User name enumeration? From what I understand it is bad security practice to display informative failed login messages like:

  The email you entered does not exist

Instead of

  Incorrect email/password combination

because it can lead to username enumeration.  Is this is really an effective way to enumerate logins?  It seems like the only way you could exploit this would be to come up with a massive list of millions of email addresses and then see if any have accounts.  Considering the number of email addresses out there this seems like a long shot.  Are there real world examples of this type of flaw being exploited?

Let me give you an example of a hypothetical yet very plausible scenario.

There is an aspiring hacker named Bob. One fine sunny morning, Bob found an SQL injection flaw in a popular social networking site named HandBook. Using said SQL injection flaw, Bob managed to dump the a list of email addresses and passwords of accounts registered with HandBook. Given that HandBook has a shitty security team, all the passwords are hashed unsalted with MD5. Cracking open his trusty rainbow table, Bob manages to recover the plaintext passwords of 86% of the user accounts.

What does Bob do next? Bob knows that 86% of the people on HandBook are teenagers. What do teenagers love more than one social networking site? Two social networking sites of course! Bob decides to try out all the email address and passwords combinations he managed to crack against the authentication service of a second popular social networking site, Chatter. Given that teenagers are teenagers, they do not have strong password policies. Bob manages to access 76% of the user accounts simply by trying the same password or a close variant. He was able to accomplish this very quickly since Chatter's login form kindly notified him when he was trying to login with a non-existent email address.

Is this a flaw? Yes, potentially. I mentioned this in another one of my answers. It has been pointed out that this might not be a major issue if the usernames of registered accounts can be enumerated in another fashion, for example through the registration page. However, many registration pages are protected with CAPTCHA, which makes automated attempts against it that much harder.


Which information does a standard router see? I currently use the WLAN of my neighbours (with their accordance). It uses WPA2 and the DSL router is a Fritz!Box 7170 (see English manual).

Which information can a user with an admin account of this router (without any modification) possible see?

Is it possible to see which websites I use? (I don't use Tor. Would this even help?)

Is it possible to see plain text passwords?

Is it possible to see download volume?

Of your three questions, the answers would be:

Yes
Yes
Yes

So if these are a worry, you need to look at mitigation. What would help is to use https in every possible case - this at least hides passwords and content, but doesn't hide which websites you visit.

Tor can help hide the websites you visit, so if that is a concern to you then yes, run everything through tor. Or you could set up a server on the Internet that allows you to connect to it via SSL and redirect to whatever website you want. This way all your neighbour will see is encrypted traffic to one IP address.

Download volume is something you can't do anything about - other than use a different route to get your data. Perhaps get yourself a router and connection to the Internet.

(Alternatively, don't go to any websites you would be embarrased by if your neighbours found out...)


DHE exchange and client authentication If a server has a known public key and a Diffie-Helman exchange is performed and signed by that key, is there any benefit to authenticating the client before establishing a secure channel instead of after establishing the secure channel? It seems to me that signing only one side of the exchange still prevents a man-in-the-middle attack.

Inspired by https://stackoverflow.com/questions/6156227/does-the-certificate-a-ssl-connection-state-points-to-change-if-i-load-a-new-ce

Client authentication is for the benefit of the server. Preventing a man-in-the-middle is a distinct matter.

If the key exchange uses DH with a signature by the server (relatively to a public key which is known to the client) then the client is protected from a man-in-the-middle: the client has a strong notion of who it should be talking to, and the signature by the server prevents an attacker from impersonating the server in any way (e.g. as a "man-in-the-middle", which is just a specific kind of impersonation).

Without client authentication, the server does not know who is contacting it. The rest of the protocol (e.g. SSL/TLS) will still provide protection against attacks in the following sense: it will be the same client all along the session, and no other party may spy on the data contents or alter the data in an undetected way. As such, a "man-in-the-middle" (as in: an attacker who acts as a relay, decrypting and re-encrypting data on the fly) is averted, because the client has verified the signature from the server, and therefore used the "right" Diffie-Hellman key, keeping any attacker out of the key exchange.

Client authentication as a signature, computed by the client with his own private key and corresponding to a public key known to the server, could help preventing a man-in-the-middle in a devious situation where the client does not (stupidly) check the signature from the server. Nothing can prevent this moronic client from connecting to a fake server, since it checks nothing and can thus be embezzled at will. However, client authentication is enough for the server to make sure that if the client talks to it at all, then it will do so in a secure way.

The key point here is a matter of definition. What is a "man-in-the-middle" ? This is a case where an attacker impersonates the intended peer (for it to be a "true middle", the attacker impersonates the server with regards to the client and the client with regards to the server). This makes sense only insofar as there is an "intended peer". If the server does not care who is contacting it, then there is no notion of "man-in-the-middle".

In the usual HTTPS scenario, the client is authenticated through a password: the client needs to be sure to talk to the right server right at the beginning (using the server certificate) because the client does not wish to send his password to anybody. The server just wants to have continuity: if it got a correct password through a SSL tunnel then the tunnel is good and will keep on being so.


How to protect a legacy Android smartphone from new exploits? My Android smartphone is many years old though still satisfies more than absolutely, I really don't want to change it for a new one. The vendor, however, doesn't seem to issue updates any more. Besides installing fresh CyanogenMod (it is not 100% compatible: there are problems with the camera and some other hardware. also another old phone of mine I still use is not supported by any custom roms at all), how can I protect myself from new Linux vulnerabilities getting discovered every day? My phones are rooted (one may say that rooting a phone is a security hole itself but this is the only way to block all the spyware stuff pre-installed by the vendor and embedded in 3-rd party apps) and I can potentially patch system libraryes but needless to say I can hardly maintain all of them myself.

It's actually impossible to keep an unsupported device completely up-to-date, since device-specific binary-only drivers often have vulnerabilities, and only the manufacturer has the sources necessary to update these. This is why CopperheadOS stops supporting phones as soon as the phone's own manufacturer stops.

If you ignore that issue (as most people do), your only real option is to completely replace the ROM. Since you mention CyanogenMod and not LineageOS, I assume you haven't tried it since 2016, if not earlier. I'd recommend trying LineageOS to see if it resolved the compatibility issues. If not, and if they're deal breakers, your only real option is to look for other custom ROMs. In theory, it'd be possible to hexpatch vulnerabilities in stock ROMs, but this very quickly becomes completely impractical.


GPG File size with multiple recipients? If I encrypt a file for multiple users how does the file size change?

Does the size of the output double for two users. How about 10 or 100 users?

GPG encrypts the file once with a symmetric key, then places a header identifying the target keypair and an encrypted version of the symmetric key. The intricate details of that are defined in section 5.1 of RFC 2440. When encrypted to multiple recipients, this header is placed multiple times providing a uniquely encrypted version of the same symmetric key for each recipient.

Thus, file size growth for each recipient is small and roughly linear. Some variation may exist for key length and padding so it's not predictable different for different key sizes and algorithms, but it's small. In a quick test demonstration using no compression:

11,676,179 source
11,676,785 encrypted-to-one (+606 bytes)
11,677,056 encrypted-to-two (+277 bytes)
11,677,329 encrypted-to-three (+273 bytes)


Having malicious code stored in your DB Let's say that there is a website which has an input field from which the input is saved to a database and then displayed somewhere else on the website.

Is it safe to only sanitize/escape the output, when the data is displayed?
Do you have to also escape the input to prevent malicious data getting into the database in the first place?

The thing that I am worried about is that even if the application handles the output by for example escaping the data from the database, but some other application may not have such mechanism to protect the users which the data is displayed to.

Is it safe to keep malicious code stored in your database for the sake of not changing the user's input as long as you can prevent it from hurting the user?

In my opinion it is a bad way to have escaped data in the database. Since the escaping rules vary depending on the input an output medium (HTML, JSON, ...) they belong at the place where you input and output data and not in the database.

I recommend to use a multitier architecture where the data tier (i.e. the database) contains the plain (unescaped) data, the logic tier (i.e. business logic) works on these plain data and only the presentation tier (i.e. website, REST API,...) cares about escaping and unescaping data. This way the data will be properly unescaped (input) and escaped (output) depending on the escaping rules of the various input and output mediums (HTML, JSON, PDF, YAML, whatever...).

  ... but some other application may not have such mechanism to protect the users which the data is displayed to.

I your fear such kind of broken applications then you should also fear applications that use pre-escaped data with HTML escaping for outputting JSON or  which escape data again even they are already escaped in the database etc. You must have clear rules how the data are stored in the database (which not only includes escaping but also character encodings like UTF-8) and applications must know and follow these rules.


programming language and security threats I am working mostly on C/C++ based enterprise applications. Now few modules are migrating to Java. Also in parallel, there has been stress on ensuring that the application has highest benchmark with respect to security.

Now, My question is -

Suppose same application is developed in all 3 languages (C/C++/Java), What are the possible areas of language specific security threats? (Like for example const string will be revealed in name mangaling. which can be possible security threat).

Any links would help me a lot.

The biggest risk in any language is to have developers who do not master the said language. Secure development requires thinking of all "corner cases" and it does not work unless the developer knows what he does at all points. A competent C programmer who does not know Java will do more secure code in C than in Java (and vice versa).

A case can be made that in languages with "strong guarantees", consequences of some programming errors are less dire when viewed from a security point of view. For instance, a buffer overflow in Java leads to an exception and (usually) termination of the offending thread, whereas in C it may lead to an exploitable hole up to a remote shell for the attacker. This makes me a bit less worried when I have to trust developers with Java code than with C code. However, other potential security-related bugs are unchanged between Java and C code (if the code builds SQL statements in a way susceptible to SQL injection, then nothing in Java will protect against that -- to some extent, easy character string handling in Java promotes SQL injection bugs).

Obfuscation is more about maintaining intellectual property than security. It will not prevent attackers from reverse-engineering your code, but it helps in obtaining legal qualification (when using obfuscation, you make it clear, or at least clearer, that you do not want the code to be reverse-engineered, thus making "trespass" more obvious in the eyes of a judge -- but details vary quite a lot depending on jurisdiction). Java bytecode is easier to reverse-engineer than compiled C or C++, but it would be wrong to claim that compile C or C++ is immune from reverse-engineering.


Is it possible for a third party to sniff data off the line to an ISP and determine what the user is doing? Can somebody hack the line between my router and service provider and monitor what I'm doing online and what sites I'm visiting?

Theoretically yes. In practice, it is a bit complex for amateurs.

In Older Times, when people used dialup modems, plugging on the line was just a matter of a pair of crocodile clips and hooking another modem, tuned to be "receive only". Nowadays, people use ADSL, coaxial cable or optic fiber, and the much higher data rates mean that inexpert plugging will disrupt the connection, making it unsuitable for passive eavesdropping. While the "physical conditions" have not changed (the spy must still reach the wire, which is usually not very hard to do discreetly in urban environments), the price of involved hardware and the level of expertise have increased.

(Edit: also, some ADSL providers use PPTP tunneling with encryption; I have seen it done in France. The apprentice spy would have to break the encryption layer as well, which would involve an even trickier man-in-the-middle attack on the physical line.)

Law enforcement agencies and other official organizations find it much easier to add their hardware directly on the ISP premises. ISP, as a rule, collaborate with authorities since they need their continued benevolence with regards to regulations on telecommunications; and that's a legal obligation anyway in most countries (yes, including whatever country you may think of as "the most democratic country in the world").

If you want to evade such surveillance, one possible method may be Tor. There can always be monitoring somewhere (if only directly on the network provider for the server) so Tor tries to hide who is doing the browsing. Also, any site which uses HTTPS provides end-to-end security (subject to the usual caveats of server certification and human user ability to dismiss warning popups): eavesdropper can know which site you contact, but not what you do on it (unless the server rats on you, which is always a possibility, or your home machine is bugged, which is no less plausible).


What's the best way to secure the responses in a single page web app after logout? I've read some of the great responses to storing and passing session keys in a single page web application (i.e., a web "site" that runs mostly on the client-side, getting data from the server by using an API). But my question is about securing (after logout) the data which comes back in the response, of which I've seen no mention.

This data is directly accessible by just about any modern browser by clicking on the developer tools view (even when using HTTPS). Thus, the following can happen:

Authenticated User (AU) uses the application and downloads secured information.
AU logs out or is logged out automatically.
Application returns to "Login" page. It looks secured, so AU does not close the tab/page.
However, Unauthenticated (malicious) User (UU) sits at desk and opens up Developer tools. In the Network section, UU can see structured JSON objects with lots of juicy information.

This does not happen in a more traditional web application, because the data is embedded in the HTML page, which is gone when the browser redirects to the login page.

We are using AngularJS for our single page web app, which recommends using a location change feature for logout, which I have confirmed does not do an actual redirect (by design); therefore the page is not refreshed; therefore the network requests can be found in the developer section.

It seems that the way to go is to NOT use the AngularJS method, and instead to break the model and to use the pure javascript redirect to refresh the site onto the Login page. This does seem to clear the network requests. Is this the recommended method?

I realize that having access to the browser means that the UU can install keylogging, screen grabbing and all sorts of things that are even worse than this scenario, and there's nothing we can do about that, but the scenario I am describing here is a very common office scenario where casual users can sit down at a browser quickly and spy some info without really doing much work. Given that we're dealing with protected health information, it remains a concern.

Encrypt the content using a session key while in transit. Decrypt the content in-memory using a variable.
At logout, explicity clear the variables containing keys and decrypted information. Also explicity clear any variables containing authentication information and any information that was used to generate the session key.
The session key can be generated out of authentication information like hash of username/password and other information accessible to both client and server, but NOT someone watching the decrypted network traffic inside a SSL session (which the developer Tools do). Also beware of "pass-the-hash" attacks on the authentication scheme - eg if you hash username/password on client side, beware that someone might find the password hash inside developer Tools and then send the hash itself to login - without knowing the password.

A suggestion is following:

1: User logs in with username and password.

2: Application sends Username, H(Username, H(Password, T), T) where H() is a hash function and T is a timestamp. Read more in 3 how the timestamp is constructed.

3: Server checks that the record is valid. This is accomplished by having T to be a timestamp that has a granularity of 1/2 of the expected validity time. This is generated by cutting off bits from a standard unix epoch timestamp. Eg, if you want validity of 5-10 minutes, remove the last 8 bits from the timestamp. At validation, check if the hash match with T=current_timestamp, T=current_timestamp-1 or T=current_timestamp+1 to compensate for a client Clock that is slightly off. This gives a validity of 256-768 seconds, which is roughtly 4-12 minutes.

4: Application now generates a session key, using H(Username,Password,T,Static salt). Save session key in variable. (this ensures session can be used for longer than 4-12 minutes). NOTE: You CANNOT use a timestamp to expire a session, you HAVE to clear the variables if you want to expire the session due to inactivity. Remember that variables are accessible to a malicious indivual if not cleared - timestamp is only used to expire a used password hash so it cannot be reused.

5: The server script generates a session key in the same way, ensuring to use only the T that was found out to be correct during validation at 3.

6: Use the session key to encrypt information in the JSON structures.

7: at logout, delete session key, username, password, H(Password, T), and H(Username, H(Password, T), T) and also any information that was transferred during session. This is accomplished by simply setting the variable to nothing, eg key = "";

The above login scheme makes Everything secure both against pass-the-hash attacks and also secures information in-transit using a unique session key. Also session keys from a Another session cannot be used to decrypt previous sessions.

This ensures information is encrypted when its visible in developer Tools. Its not possible to gain the values of variables in developer Tools after they have been cleared, ensuring no access to data.

If the computers are in a controlled segment, which they should be if you developing a Health record application that is accessed by doctors, you SHOULD disable all debug/developer functions via a Group policy. But that is hard to do if the application is accessed by patients.


SSL certificate fails to adhere to basic constraints and PCI compliance We have an SSL cert from GoDaddy and tried to run a PCI compliance check using McAfee's scan. The one problem they found was that the basic constraints / path length is not configured. Here's what they wrote back:

  An X.509 certificate sent by the remote host contains one or more violations of the restrictions imposed on it by RFC 3280. This means that either a root or intermediate Certificate Authority signed a certificate incorrectly. Certificates that fail to adhere to the restrictions in their extensions may be rejected by certain software. The existence of such certificates indicates either an oversight in the signing process, or malicious intent.

and also

  Please follow the below steps to test the vulnerability manually:
  -Use Internet Explorer.
  -Enter the URL using 'https://'.
  -Click on the Browser tab: View
  -Click Security Report
  -Click on the Pop-Up 'View Certificates'.
  -Click on the Details tab.
  -Cursor 'Field' to 'Basic Constraints'
  -You may view the 'Path Length Constraint='

  If the 'Certificate Basic Constraints' is set to False, Internet Explorer will not properly check the Certificate Authority.

  'Certificate Basic Constraints' indicates 'Path Length Constraint='.  This indicates how deep the Certificate Authority will be checked.  If the 'Path....' Is set for '1', then the Certificate Authority above will be checked.  However, if the browser checks and finds five Certificate Authority's, but 'Path....' Is set for '1', then there is a mismatch.  Internet Explorer will accept the error and not warn, but other browsers will check and warn of the mismatch.

It looks like they acknowledged the issue: http://community.godaddy.com/groups/community/forum/topic/ssl-certificate-fails-to-adhere-to-basic-constraints-key-usage-extensions/

I've looked at a few other SSL sellers like GeoTrust, Comodo, Thawte, and they all seem to have the same issue -- at least going through the steps above McAfee suggests to check. None of the online SSL checkers I tried report any issues.

Is this a fairly recent change / requirement that all these companies didn't get a chance to adjust to? Any idea how long it would take for something like this to get fixed? Are there any workarounds to this issue? Any way I could modify the SSL (Windows Server 2008 R2) to include this "Path Length" restriction?

Thank you!

The error report you link to states that the problem is in the lack of a "Key Usage" extension in a CA certificate (that is, a certificate which has been signed by an upper CA -- probably a "root certificate" -- and which is used to issue other certificates).

From the current X.509 Internet profile (this is RFC 5280, successor of RFC 3280 which itself obsoletes RFC 2459), section 4.2.1.3, the rules for that extension are the following:

when the extension is present, it restricts possible usage of the public key to exactly those listed in the extension;
usage of a key to validate issued certificates is called "keyCertSign" (so a CA which has a Key Usage extension must include that flag in the extension, otherwise things will not work);
conforming CA must include that extension in all CA certificates they issue.

So the lack of Key Usage extension in a CA certificate implies that the über-CA which created that CA certificate did not follow the rules (that's the third point, which was added in RFC 3280 in April 2002, so that's not exactly new). However, an application which uses that CA certificate without Key Usage extension is not entitled to reject the certificate path on that basis. Even though the Key Usage extension is lacking, the paths which include the CA certificate should still be validated by applications such as Internet Explorer, and indeed they are validated properly.

Resolution is easy for the über-CA: it just has to reissue the same CA certificate, with the same name and key, but this time with a Key Usage extension. This is a matter of a single signature, which involves, say, 1 millisecond of CPU time. Yet, since the lack of Key Usage extension does not prevent the CA certificate from "working", there is no incentive for the über-CA to do so (otherwise they would have done it years ago).


Encryption Laws in India Is cryptography legal in India? If yes, then what type of encryption is not allowed?

Is cryptography legal in India?

Yes, it is legal.

  If yes, then what type of encryption is not allowed?

Short answer is that there is no specific standard.
I found this website that explains various facts. I would recommend to go through it.

The [Department of Telecommunications (DoT)] is responsible for deciding what bits are allowed to route through the India's computer network. This department decides all the regulations regarding the IT services. There are different licenses issued for running different type of services. Depending upon what service you want to run you have to obtain license from the DoT. Here you can read all type of licenses offered by DoT.
The Information Technology Act 200  also doesn't talk about encryption standard to be used or allowed. How ever in various other resources there are some standards defined. For an example:

The government’s Department of Telecommunications (DoT) in the ‘Guidelines for the grant of Licence for Operating Internet Service’ (ISP Guidelines) and in the ‘Licence Agreement for the Provision of Internet Service’ (ISP Licence Agreement) that is entered into between the DoT and the Internet Service Provider (ISP) for the provision of internet services in India has laid down that the individuals and corporates while using the ISP services are permitted:

“to use up to 40-bit key length in the symmetric key algorithms or its equivalent in other algorithms without having to obtain permission from the DoT, but for use of any encryption equipment higher than this limit, the same can be done only with the prior approval of the DoT”.

Similarly standards are defined for other sectors too.

This post discusses that modifications are required to establish better IT security standards in India.


How can javascript files represent a flash-based XSS vulnerability? I am hosting a static website (no PHP etc., just HTML/JavaScript/CSS) with a security-conscious hoster that proactively removes vulnerable files. This is fine with me.

However, their last report states many instances of the following issue, with various files:

...
Sicherheitslücke vom Typ "XSS" in WordPress
/home/..../website/mediaelement-4.2.9/lang/uk.js
...

With the following explanation:

  XSS vulnerability in the Flash fallback files in MediaElement

  An XSS vulnerability was discovered in the Flash fallback files in MediaElement, a library that was included with WordPress. Because the
  Flash files are no longer needed for most use cases, they have been
  removed from WordPress.

My question is, how can a JavaScript file cause an XSS vulnerability in a flash fallback file?

Note: This is a media player, not a form processor.

Note 2: The mention of WordPress is another issue, since this is not a WordPress installation, but this is not part of the question here.

Flash applications can run JavaScript code in the context of the page that they're embedded in. Flash objects can also take external input, e.g. via the URL or flash parameters, or through a scripting API via JavaScript.

Together, a vulnerable swf file can be used to perform XSS on the site that hosts the swf file. For example, see
https://gist.github.com/cure53/df34ea68c26441f3ae98f821ba1feb9c

Based on your error message, I guess that the specific vulnerability was disclosed by this report:
https://hackerone.com/reports/299112 (currently with limited visibility in the details). According to the report, the bug was reported 4 months ago. If you really want to know the exact details, you can look up the changes from the past four months at https://github.com/mediaelement/mediaelement


change read/write user permissions in windows server 2012 from java code I would like to code the following :

In a windows server 2012-R2 administrator account, I have a my java application which launches an external application to run in a restricted user account. My java application also changes the user account windows permissions (read/write) as required.

1- Is it possible to launch an external application from a java processBuilder in one account and run the application in a different windows account?

2- Is it possible to change a windows server 2012-R2 users permission from java? only through a PS script?

Thanks

Launch an External Application

You can use ProcessBuilder to start a Process where PSExec is used to execute processes as a different user.

psexec.exe -u username -p password foo.exe

https://technet.microsoft.com/en-us/sysinternals/pxexec.aspx

Change a Windows Server 2012 R2 User's Permission

For executable file, you can use Icacls.

https://technet.microsoft.com/en-us/library/cc753525(v=ws.11).aspx

For PowerShell script, you can use Get-NTFSAccess, Add-NTFSAccess and Remove-NTFSAccess.

https://blogs.technet.microsoft.com/heyscriptingguy/2014/11/22/weekend-scripter-use-powershell-to-get-add-and-remove-ntfs-permissions/