Admin Functionality visible to basic users An application's interface is same for every type of user role. The access-matrix is also well maintained. However, the names of almost all functionalities are visible to all the users. But if the user is not authorized to a particular action, it says "Unauthorized" and then redirects the user to home page.

I am not sure should I report this one to the app owners? If I do, does it fall in the category of 'best practice' or a 'vulnerability'? Please advise.

If it is a client-server application then maybe it is worth having a look at whether it is only the client that says "unauthorized" or whether a request is sent to the server and the server gives that reply. I bet there are many poorly written software systems whose developers think the job is done when they reject a specific action on the client without securing the server's interfaces.


log user IP address per api call or per session I need to store the IP address of the user for further analysis of IP location and other security investigation.
I am creating session tokens with a 20 minutes expiration - is it sufficient to store only the IP address when the client tries to renew his session token or should I log it on every call? The issue being the log storage space...

Thanks,

If you're simply trying to grab the IP for analysis of location, then you only need that once.  Grabbing the IP multiple time, per connection will not add more information to aid in an investigation unless you're expecting the target user's IP to renew at every connection.

If you are concerned about the level of information then you may want to consider grabbing the MAC, username and or system name, if possible, in your setup.  All of these can easily be spoofed and changed, but it may provide more valuable information in the case that a target user IP is coming from a NAT'd public IP.


Is using only secp384r1 and up named groups considered okay? I found that secp384r1 is supported in almost all web browsers and it is considered secure.
My question is:
Is it okay if i use only secp384r1 and up named groups?
Are there any disadvantages considering that the server is only accessible with TLSv1.2 and up so browser support issues are almost non existent?

It seems to me that according to ssllabs.com, supporting only TLS 1.2 (or TLS 1.2 and TLS 1.3), only ECDHE with secp384r1 (no DHE, no RSA key exchange without PFS), should get you support by all the TLS clients you would care about. If in doubt, try ssltest with your server configured the way you want. You can/should try a dev server before changing config on prod.
secp384r1 is not a very good curve - it is too slow for its security level - but it should be fine. It is less used than secp256r1 so maybe the implementations are less reviewed or less optimized, but you probably don't care.


What all security do i need to check to secure my application? For an application with login and logout functionalities and browsing based upon authentication , what all do i need to secure it ?
I am basically very new to security and googling is leading to more confusion .
To start with i have decided to use JWT as the backbone . the client will log in , he/she gets a jws and the communication starts.
My First question is , do i also need to implement csrf protection for that ?
The way i see it , a malicious site or hacker will not be able to cause a csrf attack.
What else do i need to do to secure it more ?
I might have to save the token in a cookie using httpsecure. Will that be enough for the setup ?

Let's start with whether you need anti-CSRF tokens if you are using JWT tokens. The question is rather, if you are passing JWT token via cookie or not. If you don't pass the token via cookie, you don't need anti-CSRF tokens.
Regarding what you need to consider to do make you application secure. There are different approaches to application security. I would advise to download the OWASP Application Security Verification Standard and to implement at least all Level 1 requirements. Yes, there are many, but not everything will be relevant for your application. This is also a great point to start learning about application security too.


can an attacker exploit my main site from subdomain? I have an app that was in a folder on my main site's root directory www.example.com/app which was recently hacked and the entire website was offline because the server load was too high and the database was corrupted somehow.

Now, before I find the exploit in the app I would like to have it back online. Would placing it in a subdomain like app.example.com make any difference? Assuming the attacker will do the same on the new location, is my main site safer?

Now, before I find the exploit in the app I would like to have it back
  online

Now since you don't know what kind of "hack" it is.I am gonna go ahead and assume that it's a remote code execution,which means now the attacker can execute arbitrary code in the server.If that is the case then your server is compromised.The only way now is to start clean and plug the bug.

  Now, before I find the exploit in the app I would like to have it back
  online. Would placing it in a subdomain like app.example.com make any
  difference

Yes,If and only if the (application with the bug) points to a different machine then and only then is the attack separated from the main application which is now in a different machine

  Some IP is hitting the app registration form page with a GET, followed
  with a POST and then it gets redirected to the main site. I'm not a
  security expert but I'm pretty sure this is the cause for the server
  load I've mentioned and problems I've had

Now that you mention this.This seems more like a DOS or Searching a vuln of some kind.There are better solutions to prevent that like DOS Protection or even a Web application firewall along with it.

  I've checked the IP and it's responsible for 5000 attacks in the last
  days. If anyone is interested this is the IP 188.138.188.34.

Simply blacklist the I.P address and do the above things i mentioned.


Is my computer at risk of being hacked when using public Wi-Fi? I'm sitting at a cafe, using their public Wi-Fi. I don't go on sensitive sites; I basically go to a music site and listen to a live stream, for which there's no login. I don't check my email or visit any password-protected sites. Some rare times, I visit Stack Overflow, for which I'm automatically logged in. I'm using Windows 7 64-bit with AVG Internet Security.

Can someone hack into my computer and see/download my files?
Is there anything risky about what I'm doing?

Maybe.  The question is not whether there is a possibility that someone might be able to hack into your computer; the answer to that question is always yes, it might be possible.  If you are connected to a network, we can't rule out the possibility that someone might be able to attack you.  Rather, the right question is, how big is the risk?

In your case, if you use good security practices, the risk is pretty modest.  Good security practices are things like turning on automatic updates to keep all programs updated with the latest security patches, using anti-virus, using a firewall (should be enabled by default on Windows 7), and not visiting any site that requires a login over public Wi-Fi.
Not especially risky.  It sounds like your practices are relatively safe.

The biggest risk has to do with visiting Stack Overflow: because you are using a public Wi-Fi network, and because Stack Overflow does not use SSL (HTTPS), if someone there were malicious, they could steal your Stack Overflow login credentials and take control of your Stack Overflow account.  They might not be able to learn your Stack Overflow password, if you never type it into your browser while using public Wi-Fi, but they could still learn the authentication cookie that's stored in your user and that's used to log you in.  At that point, once they have the authentication cookie, they have control of your Stack Overflow account.

However, this risk is relatively modest, because it's just your Stack Overflow account, and let's be honest, it's probably not the end of the world if someone steals your Stack Overflow account.  The Stack Overflow folks know about this security risk, and they've been asked to adopt HTTPS to mitigate this risk, but they have declined to adopt HTTPS because they consider the risk to be of low-severity and they consider Stack Overflow accounts to be not important enough to be worth worrying about very much.


how can this prove a clickjacking vulnerability? How does just putting a site link in an iframe (and when opens in iframe) indicate that the site is vulnerable to a click jacking attack? I have also read that if the site is a forum base, then the vulnerability could be critical. Why? please provide some examples if possible.

Imagine facebook could be placed in an iframe. I could make a webpage with a button that says "win free bicycle!", and above that place a transparent iframe with my facebook page so that the like button is exactly above/covering the "win free bicycle!" button. If somebody clicks on that button, he will not win a bicycle, but he will instead like my facebook page without noticing it.


Sessions implemented through cookies over HTTPS I have  a question about sessions implemented through cookies. I have just started to learn about security and I apologise if this question comes across as something elementary.

Let's say I'm using HTTPS, so all cookie data is encrypted and only the server can decrypt it with its private key. But that still isn't stopping someone from sniffing my traffic, and seeing the exact same string in the headers of every request. So someone sniffing traffic can figure out that this constant string in every request header may be a session cookie. If the attacker tries changing any characters within the request body or cookie, it will appear as junk on the server during decryption.  However, even though it is encrypted, the attacker can re-submit the request and perform replay attacks, right?

Am I right to say that SSL/TLS prevents cookie tampering, but does not actually prevent stealing and/or replaying?

TL;DR: HTTPS prevents both cookie tampering and also cookie stealing and replaying by a man in the middle.

First, HTTPS not only encrypts the cookie but the whole traffic. And, due to the way the encryption is done (random IV and also different encryption key for each TLS session) encrypting the same plain data always results in different encrypted data. This means that an attacker will always see different encrypted data where the cookie is transferred. Also, replaying any encrypted data later will only result in a decryption error.

Note that there are attacks which make use of side channels (size of compressed data) to extract cookies. See Current State of BREACH (GZIP SSL Attack)? and others for more information.


What harm is there in obtaining password hashes in a Windows environment? ArsTechnica posted this article recently talking about how the power grid has been penetrated:
Hackers lie in wait after penetrating US and Europe power grid networks
Excerpt:

One tactic involved using the publicly available Phishery toolkit to send targets a Microsoft Word document that was programmed to download a template from a predetermined server controlled by the attackers.
The server would then query the downloading computer for SMB credentials that many corporate networks use to restrict access to verified users.
In many cases, the downloading computers would respond and in the process provide the attackers with the user name and a cryptographic hash to the targeted network.

But getting hashes is not the same as obtaining actual passwords.
So my question is:  What harm is there in obtaining password hashes in  a Windows environment?

For reference about those emails:  The Phishery Toolkit

TL;DR: Because of how Windows authenticates network users in a non-Kerberos (non-Active Directory) scenarios, password hashes work just as well as passwords for authenticating network users.

Long version: There are two traditional ways to use a password to authenticate someone:

The client sends the password to the server (traditionally, in cleartext, although newer protocols use encryption).  The server takes the password, hashes it, and compares it to the password hash it has stored. If the hashes match, then the client is assumed to have the correct password and is treated as authenticated.
Challenge-response: The server generates a challenge (a random byte sequence) and sends it to the client. The client takes the challenge, combines it with the client's password, hashes the result, and sends the hash to the server.  Meanwhile, the server takes the challenge, combines it with the password it has stored, and hashes the result.  If the two hashes match, then the client is treated as authenticated.

Note that, under a challenge-response scheme, the password is never actually sent to the server (which is good), but the server needs to know the password (which is bad).  The first approach is the traditional Unix approach; the second is the traditional Windows approach.

To mitigate the "server needs to know the password" disadvantage of challenge-response, many challenge-response implementations use a hash of the password.  In other words, instead of comparing the hash of (challenge + password), implementations compare the hash of (challenge + hashed password). However, in this case, the hashed password is still all you need to access the service (because a malicious client can send the hash of (challenge + hashed password) even if it doesn't know the cleartext password). So hashing passwords under a challenge-response scheme make it harder to get a cleartext password that could presumably be used to attack other services, but it makes no difference in terms of the security of the service itself.

Further reading and references:

https://www.toshellandback.com/2017/02/11/psexec/

  Once hashes are obtained, cracking them to uncover the plaintext password can be a long and arduous task (assuming the passwords don’t succumb to wordlists or rainbow table attacks).  Luckily for us, Windows will gladly accept NTLM hash values in many situations, such as accessing a network resource by its IP address (vs. hostname) or connecting to a device that isn’t joined to the Domain.  The only only time hashes would not be exchanged would be when requesting network resources in a Kerberos-exclusive environment, but that type of implementation is rare and can be problematic for many organizations to implement.

https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication

  Many (but not all) challenge-response algorithms… require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords.

https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2588057

  The UNIX scheme typically sends clear-text passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the clear-text password over the network, but it does store the 16-byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a “password equivalent.” You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should therefore treat the data stored in whatever passdb backend you use (smbpasswd file, LDAP) as though it contained the clear-text passwords of all your users.


Is there any way to detect caller ID spoofing? To be specific the main problem is that I want to detect if the caller ID of the incoming cal I get is real or spoofed? Most VoIP servers now allow their clients to use any caller ID they want. Also, before the caller hears the ring no authentication is made by the operator (for example, Vodafone or O2) to check if the caller ID is valid or spoofed.

I found something an Android app called CallerDec that has ability to check if the caller ID is valid only if the caller (not attacker) has also installed CallerDec by a verification call.

But it is not enough and it won't work if the real caller hasn't installed that app. Many banks now allow full access to someone's account by just verifying the caller ID of the caller and the debit or credit card number associated with that caller ID.  I am sure they must be aware of caller ID spoofing and have some special process for identifying spoofing.

There is a proprietary service TrustID available for business users that guarantee to detect if a caller ID is spoofed or real but as it is closed source we can't know how it works.

Although I have no firsthand experience, I've read of this being done by forwarding calls to a toll-free number, which then (by virtue of being toll-free) receives the true calling number through ANI (which is distinct from Caller ID and which supposedly cannot be spoofed) and finally forwards back to the original number.

For example, the TrapCall service mentioned here appears still to be in operation: http://www.nytimes.com/2009/03/15/us/15call.html


Should I worry if my credit card payment processor's server allows only weak SSL cipher suites? I tested their server using https://www.ssllabs.com/ssltest/ and, apart from the disappointing "B" rating (it handles financial transactions, after all), the server only allows the following two RC4 cipher suites, both of which are considered weak:

TLS_RSA_WITH_RC4_128_MD5 (0x4)   WEAK 128
TLS_RSA_WITH_RC4_128_SHA (0x5)   WEAK   128

I disabled these cipher suites in my browser (Google Chrome) some time ago, so the transaction fails, but honestly I don't want to re-enable them if they are considered vulnerable. Should I make an exception for this particular case and temporarily re-enable the ciphers or should I insist they offer a stronger cipher suite? What do you think?

Of course you should worry. If the credit card payment processor is not able to fix well known and obvious security problems (A few days ago RC4 got explicitly prohibited for use with TLS by the IETF) which are even visible world-wide from outside, how will be the status of their internal security? Note, that it might be not that bad to offer RC4 for compatibility with older clients (see the other answer about PCI requirements), but in this case it offers only RC4 to all clients.

Not only you should think in this way but attackers will also think this way and will check the providers server and infrastructure for less obvious but maybe even more serious security problems. And they will probably find them, it would not be a first. This in effect can put your customers and also business at risk too.


How can I contract an email tracking service and be silent about it? I use a customized e-mail and my web-master, who is also the domain owner,  doesn't allow me to see the settings that the DNS provides. Some DNS services provide, beside domain name registration, services like free forwarding email. Since it is possible to set up more than one e-mail to be forwarded, I'm suspicious that my webmaster is forwarding the messages addressed to myname@company.com to hisemail@hismail.com and competing with me. I installed an e-mail tracking service called bananatag and did not predict that it would send me a lot of welcoming messages and blablas. So now I'm quite afraid that my web-master is aware that I'm tracking the emails and he'll take some countermeasures like this How can I protect against email tracking services?.

Back to my question: Is there another way to know which are the computers opening the messages addressed to my account?

Email servers store all mails they forward in cleartext. That means you must trust your email service provider to not snoop on you. An automatic forwarder is not necessary to do that. There are other ways to forward the content of your emails without using email. Also, all email tracking solutions depend on cooperation of the email reader. Most email readers can be configured in ways which make it impossible to track when an email is viewed in them (for example by not loading any images embedded in an email).

When you can not trust the provider, either switch to a different one or convince your communication partners to use an end-to-end encryption system like PGP.


Is there any security benefit to separating an RFID chip from an ID badge? This seems to be a question that blurs the line between physical and IT security, but I'm hoping it's relevant enough!

In order to meet with PCI standards, our company recently switched from an open door with after-hours hand scanner, to an RFID+Security badge system.

I was just informed today (it wasn't part of our training procedures, hooray!) that keeping the RFID key fob on the same lanyard/chain/etc as ones ID badge is verboten. Now to me this seems absolutely pointless and probably more dangerous, because now if either my fob or badge is stolen it seems that the reasonable assumption would be "Oh, I just misplaced it/forgot it/it fell off in my car/etc."

Is there any valid reason to prohibit physically connecting (e.g. sticking them on the same keyring) the identification mechanism (my badge) from the authentication mechanism (my fob)?

Yes, because if you have them together and lose them anyone could walk in with your credentials. Security guards rarely match faces to cards, chances are anyone looking remotely like you would have free access.

Here's a scenario:
Employee A is going on vacation for 2 weeks. During his celebratory drinks he drops his ID+tag dongle, which he also has his unencrypted company issued USB memory stick also conveniently connected to. Unsavory character 1 picks up this handy combo, and seeing that his friend, unsavory character 2, looks a lot like this drunken idiot, and overhearing that he's going away for 2 weeks, decides to give it to UC2, who uses it to steal all sorts of company property. That's why having both together is a very bad idea.


Malicious script through sql-injection One of my customers had a problem making a post at his blog, and when I looked into the database I found out that the newsletter table (which sends emails about the blog posts) had a malicious script.

Since I'm just a rookie front-end developer, I have no clue about what would this script do.
Could anyone help me with the goal of the attacker?

Also, while looking at the ip of the attacker (which was not obfuscated) I could find that he was using a university to make it.
(Not really far from where I am and my customer's location)

I'm using a client validation and also validating the data in my back-end with regex. And this script does not match the parameters, so, I suspect he made a post to the db.

How can I prevent this kind of attack?

And what did the attacker wanted?

EDIT:

As requested, the code:

sample@email.tst
sample@email.tst' and 2*3*8=6*8 and 'sfn7'='sfn7
sample@email.tst" and 2*3*8=6*8 and "sxju"="sxju
sample@email.tst%' and 2*3*8=6*8 and 'l6b4'!='l6b4%
sample@email.tst&n945604=v918673
sample@email.tst'"()&%<acx><script >j9ml(9550)</script>
sample@email.tst_9225

Sorry if this is not the place to make this question, I thought it might not be a StackOverFlow question.

Interesting stuff. Should be rather flattering to become the target I suppose.

I've never caught anybody like that. Frankly I think the operative line is sample@email.tst'"()&%j9ml(9550) where they are apparently attempting to execute a function named "j9ml". Not exactly sure though. I wouldn't worry about it too much unless you need to maintain an ultra secure blog or there is egg on your face (spam happening or whatever).

I agree with @jcaron that the best defense is parameterizing all queries and stored procedures. Which is to say that you should use the question mark syntax which quotes all user inputs and will prevent this kind of attack.

Important to also acknowledge that it may not be a malicious attack. The kid is probably just playing around. Could conceivably even be an assignment, executing a function on a site is not necessarily malicious or illegal I don't think.


SSID rotation prevent tracking or not? The Program VirtualWifi Manager can rotate SSID's.

Does rotating SSID's  prevent the  google tracking _nomap problem?

I don't think so. There are sources that indicate that in addition to collecting the SSID, Google is also collecting the BSSID.

  The idea was to take the SSIDs and BSSIDs from the collected packets of data, and to store them in a database together with the information about the location where the SSIDs and BSSIDs were seen.
  Source

and

  Google and others like Apple and Skyhook build a Database which links WLAN BSSIDs to a geographic location. A BSSID is like the MAC Address of a access point that gets broadcasted by that access point.
  Source

Changing the BSSID of an access point is generally not something most access points let you do since it is tied to the MAC.


Outbound TFTP request to 255.255.255.255 Recently snort notified me that I have a user's computer on my network initiating an outbound TFTP request.  The odd thing is the destination is 255.255.255.255

Anyone have a clue as to what this may be?

Recored Payloads:

0000000: 00 01 72 6f 75 74 65 72 2e 63 6f 6e 66   00 6e 65 74 61 73 63 69 69 00           ..router.conf.netascii.

0000000: 00 01 42 6f 6f 74 5c 78 38 36 5c 77 64   73 6e 62 70 2e 63 6f 6d 00 6e 65 74 61  ..Boot\x86\wdsnbp.com.neta
000001A: 73 63 69 69 00                                                                   scii.

0000000: 00 01 72 6f 75 74 65 72 2e 63 6f 6e 66 00 6e 65 74 61 73 63 69 69 00
..router.conf.netascii.

That's probably a router, requesting the router.conf file in netascii encoding.

0000000: 00 01 42 6f 6f 74 5c 78 38 36 5c 77 64 73 6e 62 70 2e 63 6f 6d 00 6e 65 74 61
000001A: 73 63 69 69 00
..Boot\x86\wdsnbp.com.netascii.

That's a Windows PE attempt at booting via PXE.

Since TFTP uses UDP as a transport (keeping coding overhead very light, hence Trvial FTP), it can also be accessed by using the broadcast address allowing a machine that has booted with no configuration info about the network at all to grab configuration files or executables to assist in the boot process.

Record and track associated addresses if you want to figure out what was going on. The triage, however, is normal netboot operations. That said, this could still be handy for an intruder in some ways.


Could I recover the content of file from its checksum/hash? Let's say I have a video file that is split into multiple parts. Each piece is 2 Megabytes. I also have a list of the *insert hash name here* for each piece and also for the full file.

Now assume that I have misplaced/lost/fubar one of these pieces.

Could I retrieve the lost piece from its hash, using brute force or any other method in a human-lifespan amount of time?

A rainbow-style table would be unfeasible, I think.

Bonus numerical question - how much would it take on a medium-size distributed computing network based on mostly consumer PCs? (Example: 4 GHz CPU + entry level GPU + 8 GB RAM)

A simple answer, NO.

It is like asking, if I know, that x%4 = 3, is it possible to find the value of x? No. Surely, there would be infinite values of x satisfying this equation, but you wouldn't simply know which one is correct.

Similarly, many(or infinite) video clips could result in a given hash value(obviously, infinite video clips have to be mapped to a specific number of hash values, so collisions are bound to happen). You wouldn't know which clip is correct.

That too, in human time? No.

EDIT:
As pointed out in comments, since the file is chunked into pieces of 2 MB, there won't be infinite possibilities, but it would be pretty large(2 raised to power of 16.7 million, approximately). Brute-forcing such a large number of possibilities, in human time, is still close to impossible. But yeah, it's not infinite.


Why do I need to hide my phone's IMEI If it is a secret then why is it visible on the box, invoice and the back of the phone?
If it is not a secret then why does it have to be blurred when it gets posted online?

As @Lighty said, the IMEI is a unique identifier for your phone (not the SIM card though, that would be the IMSI).

You can think of it as an equivalent to a MAC address in Ethernet. The IMEI could be spoofed to impersonate you / your phone. Your phone could get traced in a network using the IMEI (It actually is to maintain your connection). The IMEI is also used to find stolen phones, by comparing it to the IMEI DB of the GSM Alliance, for example.

Thus, to protect your idendity, and limit tracing to legitimate usages, it may well be worth it to not spread the IMEI out in public.


Testing PHP form injection I'm writing a very small PHP app that takes input via a form. As could be expected for a first revision, the code does no escaping or sanitisation of input:

if( $_POST["var"] != "" ) {
    print "Current value: ".$_POST["var"]."\n";
}

But if I try to inject PHP code ("; print phpinfo();, " etc.) I just get it echoed back to me instead of executing it.

I'm aware of how to clean the input using htmlspecialchars, addcslashes, mysqli_real_escape_string etc. but before I use them - what syntax do I need to successfully inject arbitrary PHP code?

I have noticed that my machine has the PHP Suhosin patch installed (Ubuntu 10.10) - would that be auto-escaping/sanitising my input for me?

For that code, I wouldnt expect to get PHP injection, but I'd look at Cross-Site Scripting (XSS) instead.

For example, try injecting:

<script> alert('woot Security.SE rulez!');</script>


Learning how to code advanced Windows malware I often see advanced malware on Windows platform - rootkits, bootkits, web injection, formgrabbers, injecting into other processes etc...

Some of this looks so difficult to understand. If you knew the inside and outside of the operating system, it would probably be a better career working for Microsoft...

Aside from getting good at Win32 development, what else would be required to learn this? I would guess understanding Windows internals.

Would you like a manual on how to make rootkits, bootkits, web injections, formgrabbers and inject into other processes?

It's probably not all gonna fit here. I would suggest narrowing your question so we can provide you with technical information.

Otherwise, getting good at the internals of the OS you're trying to infect really is the only advice we can give. https://www.reddit.com/r/Malware/ is also a very broad resource where you can dig around all types of malware analysis blogposts.


How secure is opening an incoming port for a java application? If a java application is listening on UDP port xxxxx and a firewall is allowing connections to that java application through the same UDP port xxxxx, what vulnerabilities will a Windows 7 machine be open to?

After scanning for and finding the UDP port xxxxx, can a hacker or botnet gain access to a password protected system and/or upload exploits, viruses, malware, botnets, etc.?

Either my pc has already been exploited, possibly with a botnet, or my ISP is getting attacked. Regardless of how many times I change my dynamic IP, I'm getting port scans, attempts to connect to certain services such as ssh, and other phenomena.

I think you're making some incorrect assumptions about Java - Java itself does not listen on a port.  Applications RUNNING in Java do.

So Java itself, running on your PC/server isn't listening for anything.  If you're, say, running a Minecraft server, which runs in Java, then traffic to/from that Minecraft server hits both Java and the app.  If the app has a vulnerability, you can be compromised.  If Java itself has a vulnerability, you can be compromised by virtue of the fact that the JVM sits between network traffic and the app.  I am unaware of any such exploit at this time that directly targets Java via network traffic alone (i.e. a specially crafted packet that depends on the packet only rather than a vulnerability in the Java app) - most vulnerabilities are in the ways apps interact with Java.  That's not to say one does not exist - I am just unaware.

With regards to:

  Regardless of how many times I change my dynamic IP, I'm getting port scans, attempts to connect to certain services such as ssh, and other phenomena.

That's a fact of life on the internet.  EVERY public IP address is CONSTANTLY scanned for SSH, open ports, etc.  This isn't a function of your ISP or your server - it's a function of the internet as a whole.  That's why it's so crucial to have adequate firewalling in place.  You're not any more targeted than any other random IP address out there.


Is bad policy to allow a Windows service using the LocalSystem account to execute arbitrary files in an Administrator-protected folder? Since an administrator on a Windows system can install a service that logs on as LocalSystem, is it considered bad practice to allow that service to execute programs in a directory known to be protected?

For example, the administrator loads a 3rd-party service that uses CreateProcess to launch an arbitrary executable from a folder (say Program Files). Since that administrator can also change the executable in that folder, is it safe to assume that this is also secure?

Or, could this be abused by someone who happens to gain administrator access, but then use the service to launch a custom process as LocalSystem, which could theoretically hide their tracks, or be a risk for some other reason?

The concern is allowing a Windows service we control to be used to execute arbitrary code, even if it is controlled by a local administrator. Or, should all code executed by the service be signed, and known to the service?

From an authorization perspective, the difference between Administrator and LocalSystem is nearly meaningless. Either one can launch arbitrary programs as the other (although, assuming the process running as LocalSystem doesn't have access to the Administrator's password, it would need to either reset the password or create an unauthenticated Administrator token, and unauthenticated tokens have limits). So, for that purpose, there's absolutely no reason to worry about the Administrator being able to launch arbitrary processes as LocalSystem; that's already possible (with only a little work).

From an auditing / non-repudiation / incident response perspective, well, that depends what events you have the system log capturing and how well the log is protected. If you're worried about an attacker "covering their tracks", the solution is to track, quite closely, what sensitive operations are being performed (and do it to a logging system that even a privileged attacker cannot edit/erase). Create a service? Shows up in the log, with who did it. Start a service? Shows up in the log, with who started it, what file, and who it ran as. Modify an Administrators-only program? Shows who did it (and hopefully you have backups of the old version). Audit logs (and monitoring for active attacks) are very important in sensitive systems, but setting them up is not simple enough for the scope of a single StackExchange question.


Can an email address or its creation be traced back to me? I created an email address from my laptop using a VPN. I then created a blog with this email address also using a VPN. However, someone is trying to track down this site to find out who the owner is (me). Assuming there was no malfunction with the VPN, how can this person find out I created this? I was thinking that if they tried to get a court ordered subpoena for the host blog site, who could then give information about the email used to create the site. The email address is a gmail address.

Can the gmail give me away? Obviously I didn't use any phone number or any real credentials.

Given that you use gmail Google has probably a lot of history from where this account was created and used and how it relates to other google services (search etc). If Google can be forced to provide this information then it will probably easy to narrow down or find out who you are based on all this collected information.


Can I get in trouble for legitimate mistakes in bug bounty testing? During some recent bug bounty testing, I needed to record a pcap using Wireshark, then replay it repeatedly in order to stress test a locally hosted server (which is in-scope of the bounty program).

However, I unfortunately exported the pcap incorrectly, meaning that all sorts of other (internet-bound) traffic was in there. I then fuzzed this pcap using Mutiny.

So when replaying the fuzzed pcap, I accidentally sent out loads of fuzzed traffic to the internet, primarily to CDNs by the looks of it (essentially any website my computer had visited whilst recording the pcap).

This was an honest mistake, and I have now mitigated the problem by running Wireshark and the packet replay tool as a Linux group that has internet access blocked with iptables.

My concern is that I may have broken some form of computer misuse law by sending this traffic. There was obviously no intent as this was a mistake, and I didn't visibly see any results from sending the traffic, however of course there could have been an impact to the remote server - I guess I'll never know.

Has anybody experienced this before? Did the police come knocking or is it nothing to worry about?

I have a computer with a cloud company where I receive between 300 and 1,000 hacker hits a day. I keep it as a test bed (I wouldn't want it for a production service, although they main access port 25--for free mail relay...)

I talked with the ISP to see whether we could do something about it and they said there was nothing they could do that would be any different than my existing protections.

I'm pretty such that your little mistake was pretty much transparent. Your ISP may have flagged your computer, but I would not see how they could know that your traffic was illegitimate since these were legitimate, albeit repeated, hits anyway.

On my systems, I have ways to detect that someone is trying an attack and block such IPs for a while. I guess that would be the worst you would get. Nothing to worry about, really.


What if the Local Windows Cert Store is Compromised? The diagram below illustrates chaining digital certificates up to a publicly trusted Root Certificate:

(source: globalsign.com)
I have been researching how trusted root authorities (such as GlobalSign or Verisign) are used to authenticate someone's public keys to identify that person as a trusted publisher. I think I am missing something, please let me know if I am misunderstanding something here.
So digitally signing involves hashing some data (message digest) with a trusted publisher's private key. Consumers of that data can use the trusted publisher's corresponding public key to verify the hashed data. Verifying the trusted publisher's public key (certificate) all the way up to a trusted root authority establishes the trust that the trusted publisher is who they say they are, correct?
In order for this chain of trust to work, I understand the importance of keeping private keys private. But I fail to see how this offers any trust or security on a compromised machine.
Say I am a malicious attacker who is trying to spoof a user on a machine I am already in control of. Like any good malware, I am going to want the user to think what they are doing is trusted. So it seems all I need to do is blow out any relevant valid certificates in the Trusted Root CA Windows Certificate Store and replace them with bogus self-signed certificates that appear to be valid. I could even re-create a chain of trusted certificates, such as in the image above.
This doesn't seem too far fetched to me yet. So, to complete the spoof, I would have to intercept the valid data and re-sign it with my bogus publisher certificate, "trusted" all the way to the "root CA". This seems far easier than stealing a publisher's private key.
EDIT:
Is there a way to protect against such a targeted attack? For my very specific application, I need to know for sure that a cert is trusted, but that may not be possible on a compromised machine.

That does indeed severely compromise security. There are no ifs, ands, or buts about it: if you have CAs that your computer trusts but are not the real ones, anything that relies on the OS store won't work (I believe Firefox has its own certificate store, but then that has to stay secure). See: the Superfish debacle, where the problem was that a hardware manufacturer added a certificate into the Windows cert store and also included the private key on ad software shipped with the computer.

The reason this isn't such an issue in practice isn't that it's easy to mitigate; it's that it doesn't really let an attacker do anything they couldn't do anyway. Modifying the certificate store for a user requires access to that user's account or an administrative account. Modifying the certificate store systemwide requires access to an administrative account. On a machine where an attacker has this level of privilege, they can already access whatever your user account is doing. An attacker with an admin-level compromise can just install a keylogger and screen viewer.

Any security system has a threat model, which is the attack scenario it is designed to defend against. A compromised client is not part of the TLS threat model: the model only posits an attacker who can manipulate network traffic (including redirecting it to his own machines to serve up bad content). TLS is not intended to secure against a compromised machine on either end, nor is it capable of doing so.

In general, it is extremely difficult (or maybe theoretically impossible) to achieve security on a compromised machine. The correct approach is to prevent a compromise or detect and handle it, not to try to achieve security despite it.


How to use and create attack graphs I am trying to learn more about attack graphs and how they can be used. I have read a little bit about them from some simple Google searches and believe that they could be a useful tool for work. I would like to know how one could go about creating an attach graph, what use cases they are best suited for, and how to prepare a deliverable with the attach graph with recommendations that I can turn into my boss for further review and analysis.

Any help that you could provide would be greatly appreciated.

I suggest the Microsoft Press book titled "Threat Modeling"


How can it be that I can't register on a website while my VPN is on I've had problems with making a account on a website (https://etsy.com)
I tried different browsers, disabeling all my plugins with no succes.

I use a VPN service that automaticly turn on when I start my PC. My last deperate atempt was to turn my VPN of and that did the trick, I was able to register a account.

I find this very wierd, does someone have a explanation as to why this is?

It could be that the site that you were trying to connect to blocks VPNs.  There are many sites that do this - Netflix is one that is notorious for this.

It's fairly easy for sites to block VPN's, they just need to learn the blocks of IP addresses that VPN providers use to route their clients' connections through.

For more info, see https://www.howtogeek.com/403771/why-do-some-websites-block-vpns/


Is it secure not to set a user in django admin? Is it possible for someone to hack into my django admin app, if I do not create a user for it, by executing:

python manage.py createsuperuser

For example, is there a default username-password pair that someone could use to gain access to django admin?

Is it possible to login with default credentials

There is no default user, and the docs state:

  The username and email address for the new account can be supplied by using the --username and --email arguments on the command line. If either of those is not supplied, createsuperuser will prompt for it when running interactively.

As such there is no default user that you could login with.

If someone can execute arbitrary commands, could I be hacked

Yes, if someone can run the create user command they can make a new admin user and use it, but they could also run any command they like, so at that point you have already lost.


Who is the creator of the CIA triad? The Information Security goals - Confidentiality, Integrity and Availability (CIA) - are often referenced to as the CIA triad.

As I am writing my master thesis, I am wondering to which resource I should put my reference on the CIA triad?!
I've done some research on this, but it's still unclear where it originated.

It depends on whether you are talking about the concepts, the terminology, or the acronym.

Concepts of confidentiality, integrity and availability of information have been used by war generals for quite some time; for instance, one can see Julius Caesar operating along these lines during the Gallic Wars and he was certainly not the first to grasp the importance of intelligence gathering, deception, and secure communications. In fact, the very fact that Caesar was using his own primitive encryption algorithm shows that he was envisioning some interception of his messages, which implies that his enemies, although described as somewhat rustic barbarians, also mastered the said concepts.

For each actual term, see for instance this blog post from someone who apparently tried to trace their origin in an InfoSec setup, with mixed success. We may infer that finding the first use of "confidentiality", "integrity" and "availability" for information security is not an easy task, and may, at best, be ill-defined (the words existed way before "information security" became a thing, and that event is not clear-cut either, since, as said above, InfoSec was yet unnamed but already put to practice more than 2000 years ago).

The acronym (CIA) and the expression "CIA triad" seem lost in the mists of times. I see many references from the 1990s, during which some people were proposing extensions (e.g. the Parkerian Hexad) and invariably talked of "the classic CIA triad" without any reference. One can thus surmise that 20 years ago, the expression was already old and hard to pinpoint. This usually means that the acronym was not coined in a groundbreaking, seminal and well-known paper, but more probably by an inebriated researcher in the nightly aftermath of some obscure academic meeting; presumably, the coincidence with the acronym for the well-known intelligence agency met some appreciative resonance in the assembled party, and beery guffawing was likely involved.

It must be noted that cryptographic academic circles use a cousin triad: "confidentiality, integrity, authenticity", whose origin is equally untraceable.

For a thesis, there is a wonderful typographic gimmick called a footnote, which is the right place to include wisecracks, pedantic notes and other attempts at literary flourishes. I suggest something along the lines of: "The exact origins of the 'CIA Triad' expression appear to be unknown, but the underlying concepts were already operative in military contexts millennia ago, as can be seen in the works of the consulus, pontifex maximus Gaius Julius Caesar." (with a reference to the De Bello Gallico, preferably the 1519 illuminated manuscript currently kept by the British Library).


Is OWASP ESAPI still the recommended way to secure JSP pages I noticed OWASP ESAPI hasn't been updated in a while (minor update in 2016, and before 2013). Are there better alternatives to using it i.e. using a more maintained framework's utilities for say escaping and validating user inputs ala XSS prevention. Think <cout .../> or Struts 2 or any frameworks own way of outputting and escaping code. Or is it preferred from a security standpoint to always use OWASP for this? Thoughts?

The OWASP ESAPI is no longer considered a flagship or even an active project. Kevin Wall, the project owner for the Java implementation, himself back in 2014 conceded that the project is dying and said:

  I’m not, because I can’t. I, for one, can see the writing on the wall.
  (Pun intended.) All of the allegations that are being made against
  ESAPI are spot-on:

  · Only one minor point release in since
  July 2011.

  · 164 open issues, including 4 marked Critical and
  11 marked as High.

  · Far too many dependencies, something that
  has never been addressed despite being promised for almost 3 years.

  · Wiki page still in the old OWASP format.

  · Minimal signs of
  life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code.
  Zero signs of life for implementations in other programming languages.
  [Note: Discounting the SalesForce one as I’ve not kept track of it.]

  · For ESAPI for Java, a boogered up architecture where everything is a
  singleton making some things such as mock-testing all but impossible.
  Less than 80% test code coverage, in part, because of that.

  · Lack of any significant user documentation outside of the Javadoc and
  the ESAPI crypto documentation.

  · Disappointing participation
  at the ESAPI Hackathon.


EMV credit card cloning: PIN code known by a malicious person Could a credit card cloned (chip or magnetic band) if someone has it for a few seconds and knows the PIN code?

If the PIN code is changed, can the cloned card still be used?

Could a credit card cloned (chip or magnetic band) if someone has it for a few seconds and knows the PIN code?

It depends.

The magnetic band can be easily cloned and you don't even need the PIN to clone it. You only need the PIN to use the card later. This cloning is not only possible but widely done by criminals.
The chip can not be cloned, at least not with the current methods available to criminals. Even if you know the PIN code. Thus it is inherently more safe than magnetic stripe and that's why the United States mandates the use of EMV by 10/2015 (or at least the liability on misuse shifts to the one accepting non-EMV payments).  In Europa EMV is already common for years and thus cloning of credit cards is less a problem.


Is phishing ineffective against a Gmail account that has 2FA? According to my knowledge, phishing basically only steals the email id and password, right?

"Phishing" is a broad term for online social engineering attacks where the attacker impersonates somebody the victim trusts. Phishing attacks can have many goals; basically anything that the the user could be persuaded to do on behalf of the impersonated entity. 2FA protects against certain attacks, and some forms of 2FA provide better protection than others, but it's not a perfect solution.

Attacker wants credentials: get the user to enter their credentials in a web form that appears to be a trusted site. This alone won't give the attacker access to the account if the account has 2FA, but we never specified "access to the account", merely "credentials".
Attacker wants access to the account: spoof the trusted login page, and then simultaneously try to log in with the captured credentials (and forward back any user-facing prompts) so the user sees the expected 2FA behavior and approves the login / enters their access code. (This doesn't work for FIDO/U2F, but the attacker can try having their spoofed login page complain that the security key isn't working and the victim should use an alternate authentication method.)
Attacker wants access to the account contents (emails, etc.): Convince the victim to authorize an app (maybe call it "Gmail Privacy Protection" or similar) that the attacker controls, and that gets access to the user's mailbox (this exact kind of attack went around less than 3 years ago with an app spoofing Google Docs integration and then forwarding itself as a worm).
Attacker wants to control the victim's browser: get the victim to install a browser extension from a "trusted" source.
Attacker wants to take over / compromise (perhaps with ransomware) the victim's whole computer: convince the victim to run a program written/distributed by a "trusted" source.
Attacker wants the victim to send them $2500 in gift cards (this is a more common attack than you might think): convince the victim you're their boss, tell them to buy the gift cards with their corporate account and that it's covered, and to send them to somebody that is a plausible recipient (a corporate partner, or an internal team running a prize event, or whatever) but with the wrong address.
Attacker wants... you get the idea.

Phishing your credentials is like XSSing your session token. It's obvious and scary and a perfectly legitimate target, but it's far from the only thing the attacker can do, and mitigations that specifically protect against that goal usually do little or nothing to prevent other goals. FIDO/U2F security keys provide excellent protection against web-based phishing pages, but you need to use them consistently. They provide no protection against you authorizing access to an app, running code (either in a sandbox like your browser / phone, or on your computer directly), or other attacks that don't directly involve stealing the victim's credentials or login session.


How can I decrypt a Word document that I know the password to without opening it in a word processor? I got a question that I thought would be simple but it is proving to be more difficult that I thought it would be.

I got a malicious password protected Word document that I want to analyze for IoCs. It is encrypted so all I can see is "DataSpaces/DataSpaceInfo/StrongEncryptionDataSpace" when I try to analyze it with oledump or similar tools.

I know the password but I would rather not open it in a word processor to remove the password. Does anyone know of any tools that I can use to decrypt the document without opening it up in a word processor?

This one decrypts password-protected DOCX documents and has no dependencies apart from Python crypto library https://github.com/nolze/ms-offcrypto-tool


Fool SAML authentication My company's has given a corporate membership to Udemy, which is accessible from company's laptop only.

I tried to look into it and it uses SAML. If I open my company's Udemy website on any other laptop, it redirects to an IDP server (https://sso.connect.pingidentity.com/sso/sp/initsso) of my company which fails.

Can I open the Udemy site on my company's laptop, and get the SAML token/key; Take it to some other system and access the website on other laptop as well?

In the company I work for, we use SAML 2.0 authentication across all systems. If an employee is using the company's laptop, a client certificate is used for single sign-on with SAML 2.0.

However we still provide the fallback option to the user that if no certificate is sent in the SAML 2.0 authentication request, the corporate username and password can be used to authenticate in the Identity Provider.

SAML 2.0 support many single sign-on technologies to be used with it, some may be available only within your company's laptop (like a Kerberos token or client certificate). The SAML 2.0 authentication request cannot be modified during runtime since it will be created by the Service Provider or Identity Provider.

You can check with your company if providing the corporate user and password is supported.


SSH CertKey Signing Destination I'm setting up an SSH key signing server, using Neflix BLESS as the base
github(dot)com/Netflix/bless.

There is a critical option for source-address to ensure that the certificate can only be used from a list of specific IP addresses, but I cannot find an option for a destination-address to restrict access to a single server.

We are not using a bastion host and want to ensure that the signed key that is returned, isn't simply used against another server that recognizes the CA, but to which the user isn't authorized.

I've checked https://www.freebsd.org/cgi/man.cgi?query=ssh-keygen&sektion=1&manpath=OpenBSD and https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD and can't seem to find an option that would handle this.

The only thing that I've see that might lend some insight is

  ...if an implementation does not recognise a optionthen the validating party should refuse to accept the certificate.

Which makes me think that there may be some list of what some implementation supports, but I can't seem to find anything.

but I cannot find an option for a destination-address to restrict access to a single server.

This is interesting question. I didn't try that, but it looks like the same option could be used for the destination-address in the user certificates.

If it does not work, it is most probably because nobody thought about this use case so if you would like to see that implemented, you should get in touch with upstream developers, for example on their mailing list.

  Which makes me think that there may be some list of what some implementation supports, but I can't seem to find anything.

No, there is none. As far as I know, no other implementation supports the OpenSSH certificates yet.


Why Windows allows Administrator login via RDP by default? Coming from a Linux background, this seems awful weird to me. Unlike Linux, where root login is denied by default in SSHd configuration, Windows users in Administrator group are allowed to login by default via RDP.

I believe it would make more sense, to follow the principle of least privileges and defense-in-stages. Instead of exposing the administrator account for remote logins, it makes more sense to allow ONLY non-admin accounts so that, even if there are any breaches, it is possibly contained.

So, what could possibly be the reason behind this decision of exposing Admin accounts by default?

Starting at least with NT4, Windows uses the notion of domain of administration, and the administration of a machine is normally done through the network. This is a general design decision: if you know an administrator account of a machine (or of the domains it belongs to) and if the system has not be tweaked to remove default services, you can have access to any disk through the administrative shares (\\HOST\C$), you can connect to its registry, and you can generally manage its users and shares.

The RDP follows same principle: if you are allowed to administer a machine, you should have all priviledges on it. Simply you can also allow other users to use it in addition to the administrators.

Be it or not a best design is another question, but it is Windows general design.


Does today's Shadowbrokers leak affect the average Windows user? Today (on April 14) the self-called "ShadowBrokers" released a large dump of ready-to-use 0-day exploits, partly with detailed usage explanations.

Now I understand that this is really bad for companies that have internet-facing Windows Servers or other similar setups.

But for the more interesting question:
Does today's dump affect the average user behind his average consumer ISP-provided router who didn't actively set up an internet facing service on his Windows machine?

Potentially useful references:
Motherbord article.
Ars Technica article.

Microsoft have now provided an analysis of the exploits which were released in this dump.

Their analysis shows that the exploits included all have patches available for them, on suported versions of Windows.

So if a user is up to date with their patches and using a supported version of Windows these exploits should have no effect.

Where these exploits will have an effect is for users who haven't moved off out of support platforms like Windows XP.  These exploits represent an easily usable path to exploit systems like Windows XP and Windows server 2003, so this release should provide more impetous (if it was needed) to migrate to a supported platform.


Why are there places that still advises to use complex-only passwords? Why are there organizations, websites that still, in 2015 advises that people should use complex, at least 8 character long passwords?

Why doesn't they advise to use password-managers, long passwords? People will not remember complex passwords in every 90 days.

Is there some kind of old standard for the password rules? Or people don't know the math?

The same reason that people are still pushing for input sanitation in 2015: the security world moves very slowly; they adopt things at a snail's pace, and the end-users are orders of magnitude slower at changing their ways.

Once people have become accustomed to a way of doing something, anything that is contrary to that is going to be rejected for a long time, until enough people are crying about it. Even then, you're going to have a few holdouts like Dave. That's one of the core reasons why people are still proclaiming outdated practices.

Getting older people to use a password manager may be next to impossible.

  People will not remember complex passwords in every 90 days.

Most people write their passwords down and put them on their desk in the form of a sticky note, or they type it enough times to remember it, or they even store it in a text file on their desktop (groan), or they set it and forget it with a long-lasting cookie.

And if they forgot it, no problem! They'll just start the password reset process. This is normal behavior for most users.

  Is there some kind of old standard for the password rules? Or people don't know the math?

The vast majority of people, including developers, don't understand better password practices at all. Even less people understand the math or reasoning behind why something should be the way it is.

If people aren't knowledgeable, and you appear to be in the know, then people will blindly accept what you tell them... but even if they agree that password managers and pass phrases are better, old habits die hard.


Does injecting querystring values directly into HTML pose a security risk? Someone reported a bug on my site that I don't really consider an issue. My site has an URL akin to this:

www.site.com/ajax/ads.asp?callback=[text injection]

So filetype is application/json, and I don't see how that can affect security of site.

His point of contention was that it can bypass crossdomain.xml if someone visits page with this in it:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

I did a search for this but couldn't really find any information that says what he is saying is true. I need someone to tell me how serious this is, if I really need to go through my scripts to fix every instance of this bug.

Plaintext injection is an issue. Say you have a page template that looks like this:

Hi <name>,

Blah blah blah.

And you can inject  from the URL.

An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%0D%0AHi%020Foo (which could also be minified).

This will make your page look like:

  Hi Foo, you have the wrong version Flash plugin, our company policy requires that you use version vul.ne.rabl.e.

  Hi Foo,

  Blah blah blah.

The message looks like it comes from your site, and since your users trusts your site, they will likely believe the instructions that "you" have given.


In OpenVPN, is the dh1024.pem file dependent on the CA? As the question already states, I'd like to know if the dh1024.pem file, generated by ./build-dh in openvpn, is dependent on the ca.(crt|key) file.

The reason was that I needed to ./clear-all the keys, but kept the dh1024.pem file open in an editor, and re-saved it after clearing the keys. Then I went on with creating the ./build-ca, ./build-key-server and ./build-client.

For that matter, could the dh*.pem file be dependent on the server key, or on anything else? Or is it just a file with a chunk of well-computed data with no dependencies?

Kind regards.

That file has no dependency on any certificate or private key. It is not secret either. It can even be shared between various servers that don't necessarily trust or even know each other.

The dh1024.pem file contains Diffie-Hellman parameters. The DH key exchange is an algorithm played in a given finite group; namely, integers modulo a prime p. For a successful DH:

There are known parameters p (a big prime) and g (a conventional integer in the 2 to p-2 range, known as the generator).
Party A generates a random secret value a, computes ga mod p, and sends that to party B.
Party B generates a random secret value b, computes gb mod p, and sends that to party A.
Party A computes (gb)a mod p (raising the value received from B to its secret exponent a).
Party B computes (ga)b mod p (raising the value received from A to its secret exponent b).

The magic of DH is that both A and B end up with the same value, that eavesdropper cannot recompute from the two values that were sent across the wires.

In all of this, the p and g values are the "parameters" and must be known to both parties; but they are not secret. Security is ensured as long as:

p is large enough (at least 1024 bits; arguably, 2048 bits would be better).
p was not generated with a "special structure" that makes discrete logarithm easier.
g generates a subgroup of integers modulo p whose size is a multiple of a big enough prime (the order of g modulo p is the smallest integer r ≥ 1 such that gr mod p = 1; it is required that the greatest prime divisor of r has length at least 160 bits, preferably 256 bits or more).

The whole World could use the same parameters; but many people prefer to generate their own parameters, just to be sure that their parameters were not "cooked". This is what build-dh does. The resulting file (dh1024.pem) contains p and g, but nothing else. These values are not secret. They do not depend upon any external element, neither certificate, private key, or anything else.


Integration with CCAvenue payment gateway I am integrating payment gateway provide by CCAvenue india. I heard about PCI compliance and other certifications.

My question is there any certification or any thing that we as a developer need to do. Current implementation is as follows.

Web application is https
Payment gateway URL is also https
We only log the order id not card details in any conditon.

And as a developer do we need to ask any certification or complience to the payment gateway team.

PCI DSS 3.1:

  PCI DSS also applies to all other entities that store, process or
  transmit cardholder data (CHD) and/or sensitive authentication data
  (SAD).

So, if your web application is accepting credit card details from a customer, and then retransmitting them to your payment gateway, then you are subject to the PCI DSS and must fill out a Self Assessment Questionnaire (SAQ) or be audited (depending on volume).  It does not matter if you are not logging the card details; if they are transmitted via your server then you are in scope.  Even if your web page merely has an iframe so that your customers can enter their data directly into the payment gateway, you're still in scope.

There are different SAQs depending on how much you deal with card data.  The simplest is SAQ-A (used for the iframe solution mentioned above) or SAQ-A-EP for other types of redirection.  If the card data flows through your server you're looking at SAQ-D.  Here's a good link describing the nuances of what setups lead to which SAQs.


What is the XSS auditor in Chrome/Firefox and how do I find bypasses? I've been doing a lot of bug bounties lately and although I've been gaining reputation and experience, I never seem to find XSS even in private programs. Items are always being reflected as HTML.

It seems unlikely that all of these companies are properly sanitizing characters and after doing some research I think this could happening because of XSS auditors in Chrome/Firefox? I've seen mention of bypasses on twitter, but I'm not entirely sure how to find them, or how to easily identify what's still relevant.

Am I correct that in some cases the website isn't encoding my XSS payload and that the auditors themselves are making assumptions about my code and preventing an alert from firing? If so, how do I avoid this?

It seems unlikely that all of these companies are properly sanitizing characters and after doing some research I think this could happening because of XSS auditors in Chrome/Firefox?

Chrome's XSS auditor does not actually render the payload harmless, it throws a warning preventing the user from accessing the page.

If you check the source code when you get a warning, you should see that the XSS payload is highlighted as seen in the example below.

From personal experience with participating and running bug bounty programs, you do not normally need to demonstrate an XSS auditor bypass in order for your report to be valid. In my opinion, it is not a good idea to rely on the browser's auditor, especially since not all browsers come equipped with an XSS auditor (e.g. Firefox) and new bypasses are found all the time.

  Am I correct that in some cases the website isn't encoding my XSS payload and that the auditors themselves are making assumptions about my code and preventing an alert from firing? If so, how do I avoid this?

As stated above, Chrome's XSS auditor will only throw a warning. So if you see the warning shown above, you might actually have a valid XSS vulnerability.

  [...] how do I find bypasses?

Most of the bypasses that you see online require a specific context for the payload to actually work. That being said, there have been universal bypasses in the past as seen in the Chromium issue tracker. Bypasses can be discovered via fuzzing, general experimentation, or purely by chance. On top of that, some bypasses are discovered by altering a previous bypass (See https://bugs.chromium.org/p/chromium/issues/detail?id=709365 and https://bugs.chromium.org/p/chromium/issues/detail?id=738017).

In future, what I recommend doing in order to make sure that the XSS auditor never kicks in while you are hunting, is to simply fire up Chrome using the --disable-xss-auditor flag.

If you are interested in learning more about browser XSS filter bypasses, I highly recommend taking a look at "Browser's XSS Filter Bypass Cheat Sheet
" by Masato Kinugawa.


Public-key encryption for pre-shared keys with MAC What well-known algorithms are suited for the following task?

I need system A (and only system A) to be able to encrypt some data, with system B being able to decrypt it. At system B, I want to be sure the ciphertext wasn't tempered with. And I want to pre-share system A's public key (store it at system B).

I'm new to cryptography and after some digging I assumed I need a public-key encryption algorithm with MAC. I think RSA is just for this task, but not sure.

I believe you need both a general and a specific answer: general to provide a big-picture understanding of the solution and specific to guide you to particular tools.  Let's start with the big picture.

What you are describing is a signed and encrypted message which is accomplished with public key encryption.  The message is encrypted using the recipient's public key which ensures that only the recipient, using their private key, can decrypt it.  The message is signed using the sender's private key so the recipient can be sure that the message was sent by the sender.  The signature also contains a cryptographic hash of the message (encrypted with the sender's public key) at the time of the signing, which ensures the recipient that it has not been changed since the sender signed it.  If required, a trusted timestamp server can be used to add a timestamp to the message hash and encrypt the combination with its private key prior to the sender encrypting the signature so the recipient also knows when the message was signed by the sender.

NOTE: I provided a longer and somewhat clearer explanation of this process in another answer yesterday.

As far as algorithms, to code this at a low level you would need to use an asymmetric key algorithm (aka public key) of which RSA is certainly the best known, but you will need more to complete the process.  You need a hash algorithm [I recommend SHA-3.]  But you also need a higher level protocol that standardizes how the pieces are put together to ensure consistency and reliability.  These exist in a number of forms for various use cases, S/MIME, x509 and TLS are examples.

As you mentioned, you need an infrastructure to generate public-private key pairs and distribute them in a secure manner, referred to as Public Key Infrastructure (PKI).  There are a number of approaches to this that apply to different use cases.  For use inside a single organization, the Microsoft Active Directory system includes a certificate service that can issue certificates (which include the key pairs and have an expiration and a defined owner) and confirm their validity and ownership for other users.  In the public Internet environment, public certificate services are available from firms such as VeriSign, DigiCert, Entrust and many others.

Exactly how these pieces are put together is somewhat non-trivial.  If you are looking to code a solution, I urge you to research off-the-self encryption solutions that will provide the functionality you need.  Reliably building encryption code is not easy and it isn't necessary in almost all cases.  Robust solutions, both commercial and open source are quite common.

You will need to choose a hash algorithm.  I recommend the recently published SHA3 if at all possible.  Several other widely used ones have been cracked or at least shown to be weak in recent years, so it would be wise to use the newest.


Why does Authenticated Encryption not decrease confidentiality? Recently, another question here made me start thinking about authenticated encryption.

In my understanding AE allows to check whether a key is valid for decryption without even decrypting the complete ciphertext. Instead, only the MAC will be checked, which should be considerably faster.

My questions are:

Does this feature of AE make it more vulnerable to bruteforce attacks?
Why is this not significant? (It can't be, since TLS 1.3 allows only AEAD modes.)
Does the defense of AE schemes against key bruteforcing boil down to the strength of the hash function, which combines the secret key and plain- or ciphertext (depending on EtM/E&M/MtE)?

Instead, only the MAC will be checked, which should be considerably faster.

Not so. In fact, it can be the opposite.

For Encrypt then MAC, you'd have to MAC the entire ciphertext to test a MAC key
For both Encrypt and MAC and MAC then Encrypt you'd have to decrypt the entire ciphertext and then MAC the entire plaintext to test an encryption+MAC key
If the ciphertext starts with a known plaintext block, you can decrypt the first block and see if it matches to test an encryption key

The fastest of those options is the 3rd, and ciphers should still be secure against that. With a 128 bit or larger key there are just too many possibilities to guess (as long as the key is random).


Are you supposed to see Root CA in SSL chain? I'm confused in difference what browser shows as SSL chain vs what openSSL does. Example below what SSL chain looks like for https://www.comodo.com from browser and from open SSL. As you can see open SSL showing that Comodo RSA Certification Authority has actually a parent called AddTrust External CA Root while it's not being shown in browser.

CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Extended Validation Secure Server CA
verify return:1
depth=0 serialNumber = 3910805, jurisdictionC = US, jurisdictionST = Delaware, businessCategory = Private Organization, C = US, postalCode = 07013, ST = New Jersey, L = Clifton, street = Suite 100, street = 1255 Broad St, O = "Comodo Security Solutions, Inc.", OU = COMODO EV SSL, CN = www.comodo.com
verify return:1

The computed trust chain depends on the root certificates in the trust store and on the algorithm to compute the trust chain. In this specific case the server sends the following certificates:

 0 ... CN=www.comodo.com
 1 ... CN=COMODO RSA Extended Validation Secure Server CA
 2 ... CN=COMODO RSA Certification Authority

The issuer of [0] is [1], of [1] is [2] and of [2] is ...CN=AddTrust External CA Root.

The browser has a self-signed certificates for CN=COMODO RSA Certification Authority in the trust store and prefers short trust chains and thus computes a  trust chain which ends with this certificates. Note that the CN=COMODO RSA Certification Authority the browser has is a self-signed CA certificate (i.e. root CA) and not the same certificate as send by the server. They both have the same public (and therefore private) key though so that they can both be used to successfully validate the signature of CN=COMODO RSA Extended Validation Secure Server CA.

openssl has likely also this certificate in the trust store but has also a certificate for CN=AddTrust External CA Root. Since OpenSSL first tries the longest trust path it will show the path ending with the AddTrust root. If the AddTrust certificate would not have been in the trust store it would have also shown the short trust chain ending with CN=COMODO RSA Certification Authority. This would at least  be the case with OpenSSL 1.02 and later. Previous version would fail validation if the last certificate in the send chain had no issuing root certificate in the trust store.


How difficult is it for ISPs to understand a user is using VPN? If a user is using VPN, how difficult is it for an ISP to know that a user is using VPN ? If the government demands, isn't it possible for the ISP to provide a list of customers who could be using VPN by making a list of customers who are always hitting a single IP (as the user always connects to the same VPN network) ? My questions may be naive & hypothetical, but I'm curious to understand if there is anything stopping the ISPs from doing it.

If the government knows we are using a VPN, won't it get more attention from them ? I'm only theoretically curious to know why people keep saying using VPN is more secure.

how difficult is it for an ISP to know that a user is using VPN

Actual implementations of VPN vary and don't always mean that the user always hits the same IP address. But still an ISP or anybody else having access to their infrastructure could detect atypical traffic patterns (like nearly no web access but lots of other traffic) and thus conclude the use of VPN or other techniques to hide the real traffic.

  favorite
  If a user is using VPN, how difficult is it for an ISP to know that a user is using VPN ? If the government demands, isn't it possible for the ISP to provide a list of customers who could be using VPN by making a list of customers who are always hitting a single IP (as the user always connects to the same VPN network) ? My questions may be naive & hypothetical, but I'm curious to understand if there is anything stopping the ISPs from doing it.

  If the government knows we are using a VPN, won't it get more attention from them.

Depending where you live this might happen.

  people keep saying using VPN is more secure

VPN makes the data transport itself more secure by encrypting the communication and this way protects against sniffing by a man in the middle. Depending on how suspicious your are this might lead to an increased risk of getting hacked directly in order to get access to the data before encryption. Or in cases where encryption is forbidden by law it might increase the risk of getting arrested.


Is it secure to consume services over HTTPS which is not signed by a trusted CA? I am building a client application that will consume a web-service application provided by a third party service provider. The service is exposed with a HTTPS URL that is not signed by a trusted certificate authority.

Is it secure to consume their services with the current situation? Note that the service provider company is known to us and we have a business agreement with them.

You can use it safely if you pin their certificate. This adds complexity to the maintenance and deployment but it does actually improve security.

If you do not, then it depends on how they built their trust chain: if they are only using self-signed certificates, then you're out of luck and can't securely use their services. If they just use a private CA, you can still import their CA and trust it.

Overall, I would recommend you implement certificate (or root) pinning.

Edit @LieRyan made a good comment that I'd like to expend on.

In some configuration, pinning a certificate will require your to add it to the machine's root anchors lists. For instance, this is required if you're using IIS on Windows to host your application.

Now, depending on how the certificate was generated, this might be or might not be an issue. Specifically: if the certificate does have a "key usage" property and if that property does NOT list "Certificate Signing", then it can safely be used because it can't be used to sign other certificates (details are a bit more complex but that is the most important one).

If the certificate does NOT have a "key usage" property or if that property has "certificate signing", then it could potentially lead to other certificates signed by that cert to be trusted by the OS. If you implemented certificate pinning, that should not be an issue for your app (since pinning will prevent even otherwise valid certs to be used) but it might be for other part of the OS.


PHP HTTP Reverse Shell? Is there a PHP HTTP reverse shell? I haven't been able to find one, only ones that transmit using TCP packets (not HTTP).

Note, I mean actually using HTTP packets as the C2, not just transmitting TCP packets over port 80.

Metasploit just has: payload/php/meterpreter/reverse_tcp and a few variations of that.

For Windows, Metasploit has windows/meterpreter/reverse_http but again, nothing for PHP.

What you're looking for is a proper implant written in PHP which uses HTTP for it's C2, which as you correctly state isn't one of the Meterpreter options - and I'm not sure if anyone has bothered writing one.

Depending on your use case and how good your target's network detection is, you might be better off using your PHP exploit to execute a binary Mettle stageless payload such as linux/x86/meterpreter_reverse_http.


How was Freedom Hosting 2 hack possible? Today I read about anonymous attack to Freedom Hosting II, and I was curious about step 3:

How is possible to someone using a FTP client to create a symlink to /? Doesn't that require root access?

How could this kind of attack be prevented?

Source: https://motherboard.vice.com/en_us/article/talking-to-the-hacker-who-took-down-a-fifth-of-the-dark-web

No, any user on a *nix system can create a symlink to anywhere else, as long as they have write permissions in the directory where they want to put the symlink.  You don't need to be able to view the target; in fact, the target doesn't even need to exist (this is called a broken symlink).  However, if you can't view the target file, then you generally won't be able to do anything particularly useful with the symlink.

In this case we're talking about /, and / is generally viewable by all users.

There's not a lot of description in that write-up, but it sounds to me that they used symlinks to bypass a chroot attempt and trick the sftp client into allowing them access outside their home directory.


Before an attacker attempts to exploit eval(), how would they suspect that it is being used by a target application? I am asking the question in the context of XSS RCE/RFI as a result of server-side eval() exploitation. It is often recommended to avoid using it, but it is not clear to me how one would attempt to exploit something before figuring out whether it exists or not.

Would an attacker just inject code in every string passed to the server (not just user inputs), and then check whether the app breaks in some way?

The attacker does not directly know this but they scan the website with probes for detecting RCE / RFI / LFI vulnerabilities and inject specific code in requests and single GET / POST parameters.

When they know that the result changes depending on the supplied user input they test single parameters with different codes for different attacks.

eval() is mostly not needed and should never be used for input which can be manipulated by attackers.

This is also mentioned in the official documentation of PHP, where they warn about the risks.

http://php.net/manual/en/function.eval.phpCaution

  Caution

  The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.

As web developer I have never used nor needed eval().

But this is still unrelated to JavaScript, even if there is the eval() in JavaScript, but for executing only JavaScript code.


Skype security (linux)? From the following article skype & from archlinux skype wiki some major skype insecurity in linux are:

The skype binary is disguised against decompiling, so nobody is (still) able to reproduce what it really does.
It produces encrypted traffic even when you are not actively using Skype.

I have founded some solutions, including making a skype group, skype user and running form terminal with command line:

    xhost +local: && sudo -u skype /usr/bin/skype'

Some questions, is there any insecurity if I install skype from my main user account? Or does it has to be installed from the created skype user to prevent?

Is not installing skype a better option than installing skype with a special group & user?

Is not installing skype a better option than installing skype with a special group & user?

As always in computer security, not installing something is more secure than installing something.

Whether or not you choose to install skype is a cost-benefit exercise: do you believe that skype is doing something dangerous - and how much are you prepared to accept that it might, versus the benefit of using the service?

This is a decision only you can make - my only comment would be that just because Skype is obfuscated, doesn't mean it is malware. Moreover, you're trusting a huge number of other packages on the system as it is.

Now, onto some technical observations. Whilst it is certainly possible for an engineer to obfuscate the machine code in their executable, it is much harder to compensate for the fact that the binary must make system calls to the kernel to get things done. This means that you can analyse these calls, and look into them. As I understand it, skype resists ptrace (and so strace), but you could easily build a LKM hooking the system calls you wish to dump - that Skype cannot stop. From there, you could audit exactly which files skype open()'d, and so on. I've never done it - and there'd be a fair amount of coding involved (you'd get all open calls and need to filter for a given set of PIDs), but it isn't impossible.

The next technical observation to make is that the Vanilla skype presentations attached to your first link have documented the process of attempting to remove the copy protection from Skype - so I think it's unfair to say "nobody knows what it does". We have a reasonable understanding, albeit with gaps.

To answer your question - running Skype as a separate user will provide you a level of security against skype evesdropping on your documents under the following caveats:

You never hand it elevated privileges.
There are no known or unknown security vulnerabilities present anywhere in any executable on your system that skype may run to escalate its privileges or obtain your privileges.

The reason for these should be straightforward - if you run Skype as root, it can do anything. If you have a vulnerability, Skype may be able to exploit it, assuming Skype is malicious.

I've looked at this myself, and personally I suspect that the high level of obfuscation in Skype is used primarily to protect the intellectual property used in Skype - making it difficult to reverse engineer it - rather than to hide anything nefarious. After all, a reputable software vendor distributing nefarious code who is detected risks damaging their reputation considerably.


Can wireshark capture the exact payload and end point of API used by my Mobile APP? I was just wondering if someone having total control over his/her network, is running my mobile app. Also wireshark is capturing all requests made using the network. My app is calling API endpoint like http://bob.com/alice/param1/param2 and also passing the HTTP parameters.

Is wireshark capable to capture the network requests like this and is the url visible?

Also is it possible for someone to track the HTTP parameters I am passing it?

Is it plaintext if I am not using HTTPS? What if it's just a HTTP call?

If not using wireshark, is there any other way to capture network calls made by the app (android / iOS / PhoneGap / Ionic)?

Can an attacker on the network see plain HTTP requests?

Yes, they can. They can also modify the request as they want.

  Can an attacker on the network see HTTPS requests?

Depends. If the attacker is the one using your app, then they can. If the attacker is trying to spy on others, it becomes more difficult, but it is not impossible.


Should password reset disable biometric sign in until the user signs in with username and password again? Background: My team's mobile apps have biometric sign in (Touch ID, Face ID, fingerprint). You can enable and disable biometric sign in when you are signed in. You always have the option to sign in with username and password (and have to in many scenarios, if for instance your fingerprints on the device were updated).

The question is, say a user that has biometric sign in enabled goes through a password reset. There are two paths I can see:

A) Keep allowing them to sign in with biometric (Touch ID, Face ID, fingerprint). Password reset is unrelated to biometric sign in.
B) Don't allow them to sign in with biometric until they have successfully signed in with the reset password.

I'm in camp B but I can't say why exactly beyond it feels more secure. Is there any best practice here?

If this question has already been answered somewhere, or this is not the right community, please point me to the right place :)

Thanks

Edit: I've noticed a few apps fall into camp A so I'm leaning that direction now. Still curious what others think though, or if I'm overthinking this ha.

Based on your description, biometric and username/password appear to be independent authentication factors (option A). That is, if either one of them can be used to sign in and one factor is enough, then you should keep them independent for the recovery/reset process. Resetting a factor (password or biometric) should not impact the other factor.

User perspective: I forgot my password but I still have my biometric so I am going to use it to sign in and use the app. Once I am signed in, I can hopefully change my password with fewer identity-proofing steps versus a reset.

Attacker perspective: it depends on the threat model. Given physical access to the device, recovering a biometric or using a synthesized biometric to authenticate is possible but is it worth it? The answer to this question would have to come from a risk assessment of your app and associated assets, including the identity of the user.

Operational perspective: are your users going to be contacting you/Operations/Helpdesk if they aren't able to sign in because you shut off their biometric when they forgot their password and attempt to reset it? That would be expensive for Operations (each "call" costs money) + encourage more social engineering attempts.

Brand / reputation: If you shut off their biometric and self-service password reset has challenges, that sounds worse than option A. Could they be leaving angry reviews in an app store or complaining to your management / client in a corporate environment? That would be expensive to your personal brand or your company or your client.

You didn't say how the password reset works but it's worth mentioning that using a biometric to reset the password is definitely a good idea. NIST
800-63b, section 6.1.2.3 (Replacement of Lost Authentication Factor):

  Replacement of a lost (i.e., forgotten) memorized secret is
  problematic because it is very common. Additional “backup” memorized
  secrets do not mitigate this because they are just as likely to also
  have been forgotten. If a biometric is bound to the account, the
  biometric and associated physical authenticator SHOULD be used to
  establish a new memorized secret.


Does using NATO's phonetic alphabet increase password strength? Given an alphanumeric password intended to be strong yet easy to remember, we change each alphabetic character by its NATO alphabet counterpart (e.g. 'cat' becomes 'charliealphatango').

I understand that password strength increases with length, but I'm also aware that a password generated by this method would yield a much lower entropy than a random alphanumeric password of the same length.

How much does password strength increase with this method, if at all?

I understand that password strength increases with length ....

The strength increases with the amount of unknown information in the password, which often correlates with the length of the password. But in your proposed scheme you get a long password with only few information inside, at least if the attacker has detected your scheme.

Example: simplify your scheme even more and let the password only consist of different amounts of "A", i.e. "AA", "AAAA" etc. If the attacker knows this scheme then the only information to guess is the length of the password, that is a password with 20 characters will be not really be harder to crack than a password with 10 characters.

You might think that the attacker does not know your secret scheme (i.e. security by obscurity) but in reality password cracking today is no longer done with brute forcing all variations. Instead there are a lot of cracked passwords out there which are used as the basis for password cracking, that is it will try these passwords and modifications of them. Thus unless you have a very original idea chances are high that others had the same idea already and that this idea also got (or will quickly get) integrated into the password crackers.


is there any 100% secure way for form authentication and sending information from client side to server side over internet pages? i think for acquiring 100 % secure data transfer between forms on client side and c# code on server side ?
my tools :
 i  use IIS as my server and i wonder how can i reach for latest security that can be acquired in ASP.net forms and c# server side codes.

No With current technology there is no 100% secure way to transfer data over the Internet.

The best you can hope for is to follow standard best practice. In which case you need to:

Secure your web server - apply patches, hardened config, firewall
Secure your application - code to the OWASP top 10, avoid SQL injection, etc.
Use SSL to protect data in transit

Despite all these precautions there remains some risk. For example, one of your users might have malware on their computer, which captures all their web traffic.


OpenSSL vs FIPS enabled OpenSSL A deceptively simple question.

How does OpenSSL compare to FIPS enabled OpenSSL?
Is it any less secure? How do I tell?

If I were concerned about security, not the NIST standard, is there any real benefit in adhering to FIPS 140-2 standard (communicating with govt agenices notwithstanding)?

For the relationships between OpenSSL and FIPS 140-2, read this documentation.

The OpenSSL FIPS Object Module is a specific subset of OpenSSL, API-compatible with OpenSSL, and provided as source code. That module has gone through the long and painful administrative process of obtaining a FIPS 140-2 validation. It has achieved the "overall level: 1" (see the validation certificate).

The intent of FIPS 140-2 validation is to show, basically, that some level of "seriousness" was applied during the development. Validation cannot prove that there is no bug or vulnerability, but it can show that the developers applied proper methodologies which, hopefully, should avoid bugs and make the software conform to a specific set of target properties.

Now, there are some caveats:

In practice, the OpenSSL developers applied the same development methodologies for both the FIPS module, and "plain" OpenSSL. Both versions share a lot of code; the FIPS module is actually a subset of the normal library version. For the same functionalities, the plain OpenSSL should be no less secure than the FIPS module. (For functionalities which the plain OpenSSL offers but not the FIPS module, anything goes).
The FIPS module is validated only insofar as you use it absolutely unchanged. If you modify the slightest character in the source code, you are no longer covered by the FIPS validation.

The second point, in particular, implies that if a bug is found in "normal OpenSSL", and a bugfix is published, then that bugfix is not immediately imported into the FIPS module, because that would void its FIPSness. Therefore, it can be argued that the plain OpenSSL is in fact more secure than the FIPS module, since it is fixed much more quickly when holes are uncovered.

Summary: if you do not target some sort of conformance to FIPS 140-2, use the normal OpenSSL.