Secure server communication in an Android application First of all, I don't have a strong background in information security and just need some basic guidelines for my question. Posted the same question on cryptography stackexchange, but this seems to be much more appropriate place.

So there are an Android application and a remote HTTP(S) server. To access the server's functionality the application needs to receive a token (generated for each individual device based on device id), and to do this app has to provide a valid API key.

We assume the communication with the server is secure and the main danger for an attack is to reverse-engineer the application. There is no 100% defense against reverse-engineering, but app's dex executable (virtual machine bytecode) is obfuscated using specialized tools.

So the question is what the best way to store the API key?

Currently I'm considering two options:

API key is stored inside native code portion of the application, not
in plain text, but encrypted with an algorithm that is very complex
and thus harder to reverse engineer than VM bytecode. So I need a
method to eliminate replay attack, where an attacker can just call a
specific native function and get the key. We assume that all native
code is black box to an attacker.
Do not use a fixed API key at all, but use some kind of dynamic API
key to authenticate on the server to receive a token. Plus implement
all security-related stuff in native code.

API key is stored inside native code portion of the application, not in plain text, but encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode. So I need a method to eliminate replay attack, where an attacker can just call a specific native function and get the key. We assume that all native code is black box to an attacker.

This is security through obscurity. While it makes some sense to slow down attacker, it is by no means a mechanism to provide real security, e.g. attack prevention.

  So the question is what the best way to store the API key?

To define the defences you need to define threat model: what kind of threats are you protecting against? User reverse-engineering? Malware apps? Remotely rooting the device via some vulnerability? These threat vectors suggest different defences.

Putting apart security through obscurity, you might want to protect the API key cryptographically:

Make it random and cryptographically strong (e.g. hard to brute force)
Encrypt it with a secret, which is not stored on the device: PIN / password / fingerprint.
If you're protecting against the owner of the device (which it slightly feels like from what you're writing), there's no good threat prevention tactic, sorry.
To avoid replay attacks, you will need dynamic key, which gets updated upon every successful communication with server.

Notes:

Try to avoid encrypted with an algorithm that is very complex and thus harder to reverse engineer than VM bytecode, because that abuses Kerckhoffs's principle (https://en.wikipedia.org/wiki/Kerckhoffs's_principle), and it leads you to dark places.
Rely on good proven cryptography and managing the secret properly. Deriving / hiding the secret near protected data will end up bad sooner or later - that's steel security through obscurity, a good additional feature yet no foundation for good security.


Is a QR code with a secret URL that changes every 5th minute secure? I need to verify that survey respondents are in the same physical room or video chat (to prevent industry espionage). The respondents can join by scanning a QR-code that opens a URL which embeds a code with 61 bits of entropy. The code and QR changes every 5 minutes.
However, as URLs tend to be considered security by obscurity, I'm a bit uncertain about allowing QR code sign in. Is this secure, or should respondents enter the code by hand instead?
Also, is 61 bits of entropy adequate?
And if this is insecure, would changing the QR code more rapidly provide greater security? I could make the code expire in 20 seconds and swap it after 5 seconds and achieve adequate usability.

Those kinds of controls usually fail fast. It takes one person to do a video chat to another outside, and the QR can be sent in real time elsewhere.
61 bits of entropy is more than adequate for a code that expires in 5 minutes. And I don't see any problems by using an URL with quick expiration to login. It's the same mechanism that a lot of services uses for quick login. It's the magic link that, for example, Slack sends you to login.
The main issue is not the URL, is that making sure people are in the same room is not easily solvable.


Securing REST API for mobile use with OAuth I'm a complete noob about security, so please, forgive me if I say something wrong.

I have to develop a social network. The client will be an Android app and (probably) a web page for smartphones that will use a REST API. Because of the characteristics of the social network, if the info of an user is stolen, it's not very important, but, I have to identify every user by username/password login and I have to be sure that every message comes from the legit user.

I don't want to use SSL (TLS) because I don't have many resources, so I don't want to suffer the latency of SSL and I don't want to pay for the certificate. So, it would be a good idea to use OAuth for securying the REST API? Are there any better approaches?

HTTPS is an absolute requirement for authenticated communication.  HTTPS typically increases CPU demands by less than 2%,  and other than the initial handshake HTTPS will not increase network letancy.   Without HTTPS you are in violation of OWASP - Insufficient Transport Layer Security.  Security isn't just HTTPS,  if you are "securing a REST API",  you have to worry about other vulenrablites and the OWASP top 10 is a good palce to start.

(On a side note,  after so many years I'm still surprised that people think HTTPS is optional, and that somehow encryption is this huge burden. I can perform a few million AES operations per second,  and most of the time I can't load a web page in under a second.  Why do people think encryption is heavy?  I would like an explanation.)


Samsung Galaxy S7- If I drain the battery so its dead and remove the simcard, can it's location be tracked down? I got 2 questions regarding my Samsung Galaxy S7-

Q1) If I drain the battery so its dead and remove the simcard, can it's location be tracked down? I'm asking about a dead battery vs removing the battery since you can't remove a Samsung Galaxy S7 battery without special tools.

Q2) Does the Samsung Galaxy S7 have some sort of backup battery function where the phone will shut off before it completely drains? Or a second battery or way for your phone to be tracked even with a dead battery.

Ex: If your cell phone is on and you drive somewhere and lost your phone, it should be traceable. But if your battery is dead and you remove the simcard, my understanding is it CANNOT be traced and will only show the last point in which the phone was on or before the battery was dead.... but again, I don't know for sure.

#

According to some article I googled, it says it can't.

Can you track a cell phone with a dead battery?
Unfortunately a phone with a dead battery will not respond to attempts to locate it via GPS. Lookout Mobile' automatically records your android phone's last known location just before the battery runs dead

In modern phones, neither the cellular radio (used in triangulation tracking) nor the GPS are powered when a device is truly powered down and functioning normally.  Please note that standby is different than powered down and just tapping the power button does not turn off the radios, as I'm sure you know.  It isn't necessary to drain the battery.

Now if we need to talk about extremes, there are ways in which government agencies and law enforcement have been able to allegedly circumvent this limitation.  The NSA reportedly did it in Iraq in 2004 and while they aren't keen on divulging their specific methods, it is likely they did it using malware to compromise the devices remotely since they wouldn't have had physical access to the devices.  The FBI has also been reported to to do this on a smaller scale.

Physically compromised devices also allow direct access to system resources and potentially even self contained power.  This strains credibility though so I won't go in to much detail, but self-contained tracking devices are not a new technology.

Want to fool them all?  Get a Mylar bag or two and put the phone in them.  It's a lot easier and would prevent all of the above even if you are on the KGB's most wanted list!


What is an 'Orange team'? I heard that Google had an unofficial 'Virtual' team called the Orange Team that consisted of staff from outside the official security team, who engaged in a range of white hat activities to both develop their own skills, and to improve security at Google. (sort of like a team of Dick Feynmans roaming Los Alamos)

Sadly I've had trouble identifying more information about defining the role and parameters of operation of an Orange Team so one could safely and effectively establish one.

Can anyone help;

More clearly define the role of an Orange Team and its members?
Define what is acceptable practice?

In short, ensure team members can contribute to security safely, without endangering the organisation's security?

There are a number of companies that do this. Typically, the organization defines the scope of the team, clearly defines the activities, trains and supervises.

I have seen it done as part of the Security Awareness Champions programme that allows people who have been active in improving the security of their peers using the tools and processes available to everyone. This new level of training is a type of "reward" for being a leader in security among their peers.

By tapping into the Champions programme, you give employees something to aim for and you get those who are truly showing interest in security and not those who are attracted only to the "hacking" part.

After that, it all depends on what your organisation wants to tackle. I've seen phishing teams (phish your peers!), physical security teams (Mission Impossible your way into the building!), and application security teams (break our product!).


How to protect against request intercepting and parameter-tampering? My problem is that I made an app and I am making PHP Requests. I just realized that you can sniff everything on Android with "Packet Capture".

How can I make my app more secure? I thought about working with checksums
or add something like a secret key which changes every time and I decrypt this key on my server somehow.

Does anyone of you have an idea how to protect against sniffing or how I can make my request more secure? (I am using basic authentication now but this isn't good)

I am new in security.

To make it more clear: The user itself is sniffing the request. It is a game and the user is able to sniff everything (UserID, Score etc) and send a request with this parameters and set the score to 99999

You can not stop user from intercepting the traffic that your application generates. There're following alternatives that you can do for making your application works correctly :-

1)     User Secured Connection(SSL/TLS). Although users on the same network will be able to view the network traffic generated, but they'll not able to figure out any meaning out of it, as it's encrypted.

2)     For disallowing parameter tampering in your application, perform strict and robust server side validations. Use indirect-reference maps, to disallow insecure direct references to our objects. eg. Instead of UserId as parameter, set any random string "adasdfasdfasdf" as parameter, which will stand for UserId and make this parameter generated randomly everytime, the user requests the page. This'll help you to avoid parameter tampering to a great extent.

You can get more information about it at https://www.owasp.org/index.php/ESAPI_Specification#AccessReferenceMap.3CKey.3E


Why can't websockets support custom headers? This question is related to this question I asked

To summarise, I'm playing with websockets at the moment and I'm trying to understand how to authenticate a client connecting to the server using a websocket connection.

On a normal connection, I use token based authentication, I basically just get a token from the server after I log in. Every time I make a request to the server, I put it in a custom header called Authentication which my server reads it from there.

With websockets, this doesn't work because websockets do not have custom headers. I'm left with two options to pass this token.

1) putting the token in the query string - obviously not a great option. Token can be logged by server etc.

2) putting the token in a cookie - this works but only when the client and server sit on the same domain. There's also other restrictions like the client has to be a browser and support cookies etc.

Anyway, the other question is trying to find a solution, this question is about understanding why this is a problem. Why doesn't websockets support custom headers? It's unlikely to be an oversight - websockets and token based authentication are both fairly mature technologies. Is there some sort of security issue with allowing custom headers during the websocket connection?

Why doesn't websockets support custom headers? It's unlikely to be an oversight ...

I agree that this looks like an oversight.

This actually does not surprise me since in my opinion the implementation of WebSockets inside the browser was not well-thought-out in the first place. The most glaring issue is that WebSockets ignore the same origin policy or CORS restrictions, i.e. the server needs to be explicitly check the origin of the connection (Origin header) because otherwise Cross-Site WebSocket Hijacking would be possible.

This insecure-by-default design is in contrast to the secure-by-default behavior of CORS which was created a bit earlier than WebSockets. Given this obvious security problem I doubt that any security considerations played a role in not allowing custom headers as in XHR.

Note that the WebSockets protocol itself supports custom headers since it starts with a HTTP handshake similar to a normal HTTP request. It is only the browser API which is missing the ability to use custom headers.


Do I need CSRF token, and how it adds me additional protection (Angular/Node SPA) I was reading about XSRF and I'd like to ensure that I understand the problem correctly and know if my application is protected against that kind of attack.

How I understand CSRF works:

adding a random(?) string which is saved in your cookie by set-cookie header or by an javascript code (then it can't be HTTP only so I guess that is better to use set-cookie), in theory it can be accessed only from the domain it was set
that string is validated with every request by the API to ensure that request isn't made from different origin

Solution I have currently:

session is set by the server after user authentication(login) and its ID is set as HTTPS only cookie
session ID is long random string saved in DB with information about users browser user agent string, IP and user ID
JS can't access the cookie, all requests are set with XMLHttpRequest.withCredentials to pass cookie to server
session ID is validated with every request also against user agent and IP
session is valid by 10 mins but can be extended

Moreover:

I have CSP set to allow content only for a few trusted domains
I have CORS setup to allow requests from trusted origins only

As I see my session ID acts a bit similar to CSRF token.
I'd like to know do I need additional CSRF token to prevent XSRF or solution I have currently covers that vulnerability in satisfying way?

Security is area which I am new in and I don't feel confident I appreciate any help.

The token needs to be validated outside of the cookie mechanism also.

Say evil.example.com open in Alice's browser makes a cross-site request to yoursite.example.org, then the browser will send all her cookies to yoursite.example.org, including session cookies or any other cookies you may be using to prevent CSRF.

To mitigate this, you need to send the token using another method also (I'm describing the Double Submit Cookies because it is quite simple). For example, you could include a hidden field on your form:

<input type=hidden name=csrftoken value=12321231 />

On the server-side you simply check that your session value (or cookie value) that you are using for CSRF matches the one in the hidden form field. An attacker can not then forge a request because they do not know this value, nor can they retrieve it for the current user. This value needs to be generated randomly per session (using some source of unpredictable entropy).


Strange entry in Apache's ports.conf I am not sure if this may indicate a compromised server or if I'm just being paranoid.

While fiddling around with Apache and Webmin on a new Ubuntu 14.04 virtual server (as well as DNS records for its also new domain name), Apache suddenly refused to restart, with the following message:

(99)Cannot assign requested address: AH00072: make_sock: could not bind to address 54.201.82.69:80
no listening sockets available, shutting down
AH00015: Unable to open logs
Action 'start' failed.
The Apache error log may have more information.

Lo and behold, Apache's ports.conf contained the following:

Listen 8080
Listen 54.201.82.69:80

Port 8080 was put there deliberately for testing, not very long before. The IP address followed by port 80 just appeared out of thin air. Upon investigation *.com.com resolves to this IP, which seems to be a host for malware.

On the other hand, it seems at least conceivable that some kind of script or automated process (maybe Webmin?) incorrectly resolved a hostname with an extra ".com" on the end and, for some bizarre reason, shoved it into ports.conf. Also, had this been maliciously inserted by an intruder, I have no idea what it would accomplish.

The only other program that should have messed with Apache's configuration was roundcube webmail, from an official repo. There is no one else with access to this server. The auth log shows a number of unsuccessful SSH log in attempts from various IPs, in the several hours that the server's been up, but no successful log ins other than my own.

I don't know if I should chalk this up to some strange configuration snafu or change all the passwords and start clean with a restrictive firewall.

Looking up the address in the ARIN database the following results are given:

NetRange:       54.192.0.0 - 54.207.255.255
CIDR:           54.192.0.0/12
NetName:        AMAZON-2011L
NetHandle:      NET-54-192-0-0-1
Parent:         NET54 (NET-54-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS16509
Organization:   Amazon Technologies Inc. (AT-88-Z)
RegDate:        2013-06-19
Updated:        2013-06-19
Ref:            http://whois.arin.net/rest/net/NET-54-192-0-0-1

OrgName:        Amazon Technologies Inc.
OrgId:          AT-88-Z
Address:        410 Terry Ave N.
City:           Seattle
StateProv:      WA
PostalCode:     98109
Country:        US
RegDate:        2011-12-08
Updated:        2014-10-20
Comment:        All abuse reports MUST include:
Comment:        * src IP
Comment:        * dest IP (your IP)
Comment:        * dest port
Comment:        * Accurate date/timestamp and timezone of activity
Comment:        * Intensity/frequency (short log extracts)
Comment:        * Your contact details (phone and email) Without these we will be unable to
identify the correct owner of the IP address at that point in time.
Ref:            http://whois.arin.net/rest/org/AT-88-Z

OrgAbuseHandle: AEA8-ARIN
OrgAbuseName:   Amazon EC2 Abuse
OrgAbusePhone:  +1-206-266-4064
OrgAbuseEmail:
OrgAbuseRef:    http://whois.arin.net/rest/poc/AEA8-ARIN

OrgNOCHandle: AANO1-ARIN
OrgNOCName:   Amazon AWS Network Operations
OrgNOCPhone:  +1-206-266-2187
OrgNOCEmail:
OrgNOCRef:    http://whois.arin.net/rest/poc/AANO1-ARIN

OrgTechHandle: ANO24-ARIN
OrgTechName:   Amazon EC2 Network Operations
OrgTechPhone:  +1-206-266-4064
OrgTechEmail:
OrgTechRef:    http://whois.arin.net/rest/poc/ANO24-ARIN

NetRange:       54.200.0.0 - 54.203.255.255
CIDR:           54.200.0.0/14
NetName:        AMAZO-ZPDX6
NetHandle:      NET-54-200-0-0-1
Parent:         AMAZON-2011L (NET-54-192-0-0-1)
NetType:        Reallocated
OriginAS:       AS16509
Organization:   Amazon.com, Inc. (AMAZO-47)
RegDate:        2013-07-17
Updated:        2013-07-17
Ref:            http://whois.arin.net/rest/net/NET-54-200-0-0-1

OrgName:        Amazon.com, Inc.
OrgId:          AMAZO-47
Address:        EC2, EC2 1200 12th Ave South
City:           Seattle
StateProv:      WA
PostalCode:     98144
Country:        US
RegDate:        2011-05-10
Updated:        2014-10-17
Ref:            http://whois.arin.net/rest/org/AMAZO-47

OrgAbuseHandle: AEA8-ARIN
OrgAbuseName:   Amazon EC2 Abuse
OrgAbusePhone:  +1-206-266-4064
OrgAbuseEmail:
OrgAbuseRef:    http://whois.arin.net/rest/poc/AEA8-ARIN

OrgTechHandle: ANO24-ARIN
OrgTechName:   Amazon EC2 Network Operations
OrgTechPhone:  +1-206-266-4064
OrgTechEmail:
OrgTechRef:    http://whois.arin.net/rest/poc/ANO24-ARIN

OrgNOCHandle: AANO1-ARIN
OrgNOCName:   Amazon AWS Network Operations
OrgNOCPhone:  +1-206-266-2187
OrgNOCEmail:
OrgNOCRef:    http://whois.arin.net/rest/poc/AANO1-ARIN

It's an amazon hosting service with 287(as of this time) domains hosted on that address. Reading the webmin installation page you must

  Enter the same login credentials that you used to log in to your
  server via SSH. This user must have root privileges via sudo.

Webmin listens by default on port 10000:

https://server_IP_address:10000

It is possible that you installation was discovered by a crawler, and the authentication was bypassed(as the address is the public address of the given work station). Strangely, altering those configurations doesn't benefit any potential attacker. However, since the given address is not related to any utilities that you've used it is recommended that you reinstall and start clean. Optionally you can write an email to the abuse address above, and ask for details on traffic from that box to your own if possible.


Is this code vulnerable to Reflected XSS? I'm doing a pentest and came by this code:

   (function() {
        var subdomain = (function() {
          var query = /[?&]css=([^&#]*)/i.exec(window.location.search);
          if(query) {
            return query[1];
          }
          var URL = window.location.host.split('.');
          if (URL.length > 1) {
            return URL[0];
          }
        })();
        if (subdomain) {
          var link = document.createElement('link');
          link.rel = "stylesheet";
          link.href = "/" + subdomain + ".css";
          document.getElementsByTagName('head')[0].appendChild(link);
        }
      })();

It adds a CSS file to the header for rebranding.
The target URL looks like this:
http://some.company.com/p1=test&css=custom
We have controlled the subdomain parameter here which equals to either query or URL[0].
query is the result of /[?&]css=([^&#]*)/i.exec(window.location.search); which equals to custom in this case.
if the query is not available in URL, then URL[0] equals to some here, I can't think of doing anything useful using URL[0] because, in order to control its value, I have to change some to something else which completely changes the URL and points to some other irrelevant page.
Anyway, The final CSS URL would be "/custom.css" or "/some.css" if the CSS parameter is not available.
I tried some payloads to exploit this but all failed.
Any ideas if this code is vulnerable and how can it be exploited?

Yes, this code is vulnerable, but not to XSS. The subdomain variable's value can indeed be controlled by an attacker, but that variable is only used to set the href parameter of a CSS stylesheet; which won't accept JavaScript code. However, controlling this value does still allow CSS injection.

The stylesheet's href is prefixed by /, but an attacker can still point it to an arbitrary page by adding another slash to form a protocol-relative URL pointing to the attacker's server. (E.g. //evilsite.com/payload.css.) This would allow the attacker to get complete control over the site's appearance, if not it's functionality, which could be used to trick users into taking actions they wouldn't otherwise take. (For example, add a banner telling users they need to reset their password, then style the user settings page to make their public profile description field look like the input box for "current password".)


Website using Windows integrated - can user get locked out I have a website that the IIS folder is set to Windows, that's the windows integrated authentication. It is available from the reverse proxy so any Internet user can access the URL. They then get prompt for credentials. Suppose they know a username, can they try several attempts to lock out the account? There is not special monitoring or protection, it's a simple IIS reverse proxy.

Yes, if the user authenticates against a domain controller, then bad password attempts will lock out the account in accordance with the security policy that applies to the account. (The domain controller doesn't care where the authentication attempt comes from.)


Why does IV not need to be secret in AES CBC encryption? According to Wikipedia, the initialization vector (IV) does not have to be secret, when using the CBC mode of operation. Here is the schema of CBC encryption (also from Wikipedia):

What if I encrypt a plaintext file, where the first block has a known, standardized structure, such as a header?

Let's imagine the following scenario:

I encrypt file.pnm using AES-CBC. The pnm file has a known header structure, such as:

P6
1200 800
255

Moreover, the dimensions (1200 x 800) and color mode (P6) can be guessed from the encrypted file size.

If both IV and the first block of plain text are known, doesn't this compromise the whole CBC chain?

I think it's easier to split this into its component parts, and consider them as separate entities: AES and CBC.

AES itself does not "basically consist of XORing together chunks of the block" - it's a much more complicated affair. Ignoring the internals of it for a moment, AES is considered secure in that without knowing the key, it's practically impossible to recover the plaintext or any information about the plaintext given only an encrypted block, or even in situations where you're given parts of the plaintext and you need to find the remainder. Without the key, AES might as well be a one-way function (and there are MAC schemes which rely upon this!). Discussing the technicalities around the security of AES and similar block ciphers is extremely involved and not something I can cover in an answer, but suffice to say that thousands of cryptographers have been looking at it for almost two decades and nobody has found anything remotely practical in terms of an attack.

The diagram you posted above describes CBC. Block ciphers, such as AES, aim to be secure for encrypting one block with a secret key. The problem is that we rarely want to just encrypt one block, but rather a data stream of indeterminate length. This is where block modes, like CBC, come into play.

Block modes aim to make ciphers secure for encrypting multiple blocks with the same key. The most simple block mode is ECB, which offers zero security in this regard. ECB involves independently encrypting each block with the same key, without any data fed between blocks. This leaks information in two ways: first, if you have two identical plaintext blocks, you'll get two identical ciphertext blocks if you use the same key; second, you'll get two identical ciphertext streams for two encryptions of the same message with the same key. This is a problem as it leaks information about the plaintext.

CBC solves this problem by introducing a "cascading" effect. Each plaintext block is xor'ed with the previous ciphertext block, resulting in originally equal plaintext blocks no longer being equal at the encryption step, thus no longer producing equal ciphertext blocks. For the first plaintext block, there is no previous ciphertext block (you haven't encrypted anything yet), and this is where the IV comes in. Consider, for a moment, what would happen if instead of an IV we just used zeroes for the -1th block (i..e the imaginary ciphertext block "before" the first plaintext block). While the cascade effect would make equal plaintext blocks produce different ciphertext blocks, the same entire message would cascade the same way each time, resulting in an identical ciphertext when the same full message is encrypted multiple times with the same key. The IV solves this. By picking a unique IV, no two ciphertexts are ever the same, regardless of whether the plaintext message being encrypted is the same or different each time.

This should, hopefully, help you understand why the IV doesn't need to be secret. Knowing the IV doesn't get an attacker anywhere, because the IV is only there to ensure non-equality of ciphertexts. The secret key is what protects the actual data.

To emphasise this even further, you don't even need the IV to decrypt all but the very first block. The decryption process for CBC works in reverse: decrypt a block using the secret key, then xor the result with the previous ciphertext block. For all but the very first block, you know the previous ciphertext block (you've got the ciphertext) so decryption is just a case of knowing the key. The only case where you need the IV for decryption is the very first encrypted block, where the previous ciphertext block is imaginary and replaced with the IV.


How could a shared password database be implemented? In the traditional form, a password database is similar to any other database file, except the contents are encrypted using a key derived from a passphrase entered by the user. The user enters their passphrase, decrypts the database, reads some entries, writes/changes some other entries, re-encrypts the database and writes it back to disk.

Say we wanted to extend this concept to a shared environment. Say our database has ten entries (0 through 9) and three users (Alice, Bob, and Carl), each with their own unique passphrase. To further complicate the scenario, Alice should be able to access all the entries, Bob should only be able to access entries 0-4, and Carl should only be able to access entries 5-9. If Alice changes one of the entries, Bob or Carl should see the updated value (if they have access). If Bob or Carl changes one of the entries that they have access to, Alice should see the updated value.

I'm curious if there is a way something like this could be implemented securely. All the approaches I've been able to come up with either require there being some sort of "master" key being stored alongside the database, thus leaving a big opportunity for anybody who gains access to the filesystem or memory of the server -- or storing a uniquely encrypted copy of each set of entries for each user. But that would break the scenarios where one user needs to update a value in a way that the other users can see.

Is there a way to do this, or some subtle way the requirements could be tweaked to make the system less paradoxical?


Can a self-root certificate spy on me without a vpn or proxy on iOS? Can a self-root certificate (implemented via mobile configuration) spy on me without a VPN or proxy on iOS?

Certificates are used to verify the identity of the remote end of a connection. You can think of them like picture IDs or driver’s licenses.

A certificate is not an active thing. Certificates cannot spy on anyone.

Like a driver’s license, a certificate shouldn’t be easy to counterfeit. If a certificate is issued by a reputable service, it can’t be.

But if you self-sign it, you aren’t a reputable service. You may trust it, but nobody else should.

A self-signed certificate is fine for protecting your own private communications, but is worthless to prove your server’s identity to anyone else.


In the Diffie-Hellman key exchange, how is the shared base key 'p' known and how are A and B, protected from Eve? I'm trying to wrap my head around Hellman, Diffie, and Merkle's key exchange design, but after reading the Wiki article about it, I can't figure out how the commonly known factor ('p', I think) comes to be?

In the initial laymen description, they first describe it with: "Note that the yellow paint is already agreed by Alice and Bob". Yet the original description of the exchange is: "The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key."

Where does the shared base 'paint' (which I understand to be a commonly known prime number) come from? Is it built into the algorithm itself? Presuming anyone could know it, why isn't that a problem in preventing man-in-the-middle attacks from hijacking both connections with their own key and providing a 'translation' service between two encryption keys based on the attacker's private key?

The trick is that Alice and Bob can share non-secret information freely; they can agree that yellow will be their base color and it doesn't help Eve at all if she finds this out.

When Eve intercepts the green paint Alice has sent to Bob, she knows it was made with yellow and some other color, but figuring out the other color is too hard to do even with this much information.

And yes, man-in-the-middle is a problem; man-in-the-middle is specifically an attack on the key exchange part of a communication. Diffie-Hellman doesn't help with that.


get ip address of person from facebook chat A person was bugging my friend not necessarily threatening, but like sending useless messages for a long period of time on facebook.
Is it possible to obtain the IP address of such person?
(and then through IP locate the person?)

IP addresses are rarely a good way to identify someone: home IPs change often depending on the ISP, and the NAT'ed IP won't necessarily enable you to legally implicate someone within the network if there are multiple clients.

The best way to de-obfuscate someone is to convince them to give up their info willingly. Standing up a forum or website that you convince them to visit or register for is one method with the fewest legal pitfalls(provided you don't misrepresent yourself). This will also enable you to see the IP they connect from, but as noted, this is not sufficient by itself to determine the identity of someone.

To be sure you find the IP of the person you intended and not some random visitor, you can configure your site to redirect all requests to some default page (e.g. index.php), and hand them a link with some random junk appended:

hxxps://mysite.io/j4hhh5j3 -> 503 redirect to index.php

Then just locate that GET request within your apache access.log, and voila.

Keep in mind that this is just surface-level stuff; it takes 20 minutes to get a domain, get an ssl cert (zerossl.com is a good way), stand up a server on AWS, and set up a simple php website.

If this seems too complex, you probably shouldn't be trying it. Report and/or block them and move on.


Is RSA key-like browser authentication feasible? I see that password based authentication is out of favor today, and Internet is moving toward RSA keys-based authentication.

Coming from that fact, I am wondering if there would be a real benefit to widespread its use for regular websites? I see the usage as follows, and it's exactly the same as you would normally expect:

When signing-up onto a web-resource, User's browser generates the public-private pair, as well as scope she/he is willing to give to this key (not root/admin by default)
Browser encrypts the private key, and User communicates the public key to the web-resource

For all other requests, User is automatically logged in thanks to the private key stored in browser. Note that the user could (should) also sign-in (sign-up) with a federated profile, and only this method would provide the root/admin-like scope. This root user will be able to revoke key-pairs if they are compromised.

Wouldn't it resolve the 'N passwords for N websites' problem which everyone is facing, since only 1 admin password exists (which is not known by the web-resource)?

Yes, I kinda feel like reinvening the wheel, and if this is so obvious, why nobody seems to use it?

Your intuition is correct! There are two protocols that I'm aware of which use public-key crypto as a way to log into websites. (neither are actually SSH though)
TLS client certificates
We are all familiar with TLS (that green lock icon in your browser bar). Typically it serves two purposes:

Encrypt the traffic between you and the server.
Prove that the server is who they say they are.

By clicking on the green lock, you can see the server certificate for the site you are currently connected too.
It turns out that TLS also supports a mode called "mutual authentication" where, in addition to the server providing a certificate to prove its identity, you (the user) do too.

To do this, you need to get a personal certificate (usually issued by the website in question) and import both the cert and the matching private key into your browser (usually via a .p12 file). When connecting to a site the requires it, you'll see a popup like this:

FIDO Universal 2nd Factor (U2F) USB sticks (think Yubikey)
This is the technology where you plug a USB crypto device into your computer and a website communicates with the device to authenticate you. This has pros and cons compared to client certificates, but one big pro is that the private key is stored in cryptographic hardware, so even someone with admin access to your laptop can't make a copy of your key.

From wikipedia:

Universal 2nd Factor (U2F) is an open authentication standard that strengthens and simplifies two-factor authentication (2FA) using specialized USB or NFC devices based on similar security technology found in smart cards.
U2F Security Keys are supported by Google Chrome since version 38 and Opera since version 40. U2F security keys can be used as an additional method of two-step verification on online services that support the U2F protocol, including Google, Dropbox, GitHub, GitLab, Bitbucket, Nextcloud, Facebook and others.


Snort report - 1000+ alerts in 1 minute from port 5060 I woke up this morning and could see over 1000+ of these alerts.

They came in the time space 23:34 - 23:35.
Can anybody tell me what that was about and should I be worried for an eventual DDoS attack?

I am running pfsense and behind that box I have my LAN and a NIC where my server is in a separate environment.

This is probably a bad configured scanning(attempting) of the communications compagny in Portugal. Since the ip-range might be the same as yours. Or they misconfigured some other connection ip's.

Nevertheless i don't think this commucation compagny is trying to hack you. Unless you have valuable information ;).

Greets

Samuel

More info:

inetnum:        87.196.128.0 - 87.196.255.255
netname:        NOS
descr:          NOS COMUNICACOES S.A.
country:        PT
admin-c:        NVSA1-RIPE
tech-c:         NVST1-RIPE
status:         ASSIGNED PA
mnt-by:         IP-MNT
source:         RIPE # Filtered

Wikipedia Source Nos communications:

  http://en.wikipedia.org/wiki/NOS_Comunica%C3%A7%C3%B5es


Is it possible to restrict USB keys to only certified ones, and block that key's access on other computers I am working on security for an organisation, we have purchased some encrypted USB keys but wanted to stop any employees leaking data. is there any way to stop their laptop accepting any key but the encrypted one's and also stop the use of the encrypted keys on other PC's.

I do not want to prevent any specific attack, but it is just the users of the system are not very well informed, and I don't want them to leave any data on their home computers or for the data to be given to someone else who have knowledge of the encryption code.

Almost, but not really.

Each USB device has a "Vendor ID" and a "Product ID", which the OS uses to determine which type of device it is. These IDs are officially registered and guaranteed unique. And you can set policies in Windows to restrict which device IDs are allowed to connect. Problem solved.

Except no. It's up to the device to correctly report its IDs. And it's possible (and in fact common) for malicious devices to impersonate legitimate devices in order to bypass this feature. There's even a pass-through USB device you can use to change the ID seen by Windows for any USB device specifically to thwart this feature.


What kind of attack is a request like this? The number of request strings like this one seems to have increased over the last weeks. They all have in common, that they contain a combination of google adwords / google adsense parameters and sql injection.

The decoded value of the request string is

/?gclsrc=aw.ds&gclsrc=aw.ds& and 1>1

I can see

a duplicate gclsrc parameter
an sql injection attempt

... but why this combination? Is it a technique to grab adsense revenues while sqli probing?

This could be an initial control test for blind AW injection.

Typically those start with a true/false test.

So perhaps they are testing 1>1, which is always false.

Then they will also test 1=1, which is always true.

And look for a difference in the response

https://en.m.wikipedia.org/wiki/SQL_injection#Blind_SQL_injection


How to manage API keys I'm trying to consume a payment processor API (not developed by my), but (being honest) I don't know anything about security, I don't understand API keys and authentication, I have multiple questions about API's that I couldn't resolve no matter how much research I did, the questions are:

What could happen if someone steal the payment processor API keys? I mean, I know for example that if someone steals your Google API keys he can use Google API charging it to my credit card (there are multiple cases all around the world), but in this case the API keys are used to process the payment, I don't understand what they can do with my API keys

Where should I store my keys, I'm using React.js CRA as Front-end and PHP as backend, I was making some research and this is what I found:https://medium.com/better-programming/how-to-hide-your-api-keys-c2b952bc07e6
the post says: "if you wish to totally mask your key, you should make a backend that proxies your requests, and store the API key there", so at this point my question is should I send the request to my backend then my backend sends a request to payment processor API?.

When developing my own API should I use authentication no matter what I am going to do?, I mean, I know that authentication is for user login functionalities, but, should I use Auth to bring products from a database?

When generating API keys for others to use my service, is it safe to store them in a database?

Please try to be gentle I don't understand security, I'm trying to do my best

An API Key is a unique identifier that the API provider will have linked to you. It is imperative for you to make sure that your API keys are not exposed to the rest of the world. What could go wrong? Well, that depends on what the APIs can do and what your keys have permissions to do.

What could happen if someone steal the payment processor API keys? I mean, I know for example that if someone steals your Google API keys he can use Google API charging it to my credit card (there are multiple cases all around the world), but in this case the API keys are used to process the payment, I don't understand what they can do with my API keys

When someone gets hold of your API keys, they can do whatever you can do with the APIs on your behalf. So for example, if they get hold of some credit cards, they can charge use the payment processor's APIs to make new credit card charges using your identity and defraud the card owners.

Where should I store my keys

You should store your keys at any place that can't be accessed by general users and is harder to access for anyone accessing your code. Often people use services like keyvaults (provided by all major cloud providers and some independent vendors like HashiCorp). Take a look at this blog post for PHP based examples.

When developing my own API should I use authentication no matter what I am going to do?, I mean, I know that authentication is for user login functionalities, but, should I use Auth to bring products from a database?

It is not mandatory for each API to have an authentication requirement. For example the service health endpoints are usually unauthenticated. It is your decision on which API requests should come only from authenticated/authorized users. If you think that anybody(regardless whether they are a user or not) should be able to view products from a database, then its okay to not authenticate the endpoint.
When you make an endpoint public, you should ensure that you don't end up adding some code path that allows users to view something without authenticating. For example, if you have scenarios where everyone can see the basic products but you need to have an account to view say the VIP products, then its your responsibility to ensure that your public endpoint doesn't have any way to show the VIP products.

When generating API keys for others to use my service, is it safe to store them in a database?

Whether it is safe to store them in a DB or not depends on your threat model. There is a risk of someone gaining access to your DB and as a result, getting access to the keys. If you encrypt the keys before storing them, then you reduce the risk a bit. There is actually an answer about this on stack overflow: https://stackoverflow.com/questions/37951220/storing-api-keys-on-server/37953361


mysql security logging Is there any logging available that logs mysql connection attempts to the port, login attempts, and times succeeded with username, IP address and date time?
Im trying to detect brute force attempts.
Is there a way to setup a mysql automatic brute force delay?

If you have people connecting to mysql you have already seriously messed up.  You need to change your firewall settings to make sure that only trusted hosts can connect and no one else.

An attacker could easily summon a bot net of 1,000,000 in size to brute force your mysql server.  You need a white list approach to this problem.


Does CSRF work when the target site is not open on a tab? This is an example attack scenario of OWASP for CSRF

  The application allows a user to submit a state changing request that
  does not include anything secret. For example:

  http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

  So, the attacker constructs a request that will transfer money from
  the victim’s account to the attacker’s account, and then embeds this
  attack in an image request or iframe stored on various sites under the
  attacker’s control:

  <img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

  If the victim visits any of the attacker’s sites while already
  authenticated to example.com, these forged requests will automatically
  include the user’s session info, authorizing the attacker’s request.

I do not understand the last paragraph though. If I log into an account on example.com and then leave the webpage without log off, and now I visit the attacker's site, does this attack work? Or in order to work, it needs that I be on the site?

When you log in to example.com, your browser stores a session token in a cookie. This session token uniquely identifies your logged-in session with example.com. Every time your browser makes any request to example.com, that request includes your example.com cookie data, including your unique session token.

With that in mind, consider the fact that a Web page can make your browser attempt to fetch any resource on the Web, e.g., through <img> or <iframe> tags. If a page includes a tag that asks your browser to fetch a page from example.com, the fetch will include your session info. The request is done in the context of your logged-in session (i.e., the fetch is being done as your logged-in example.com user account).

If the fetch of the example.com resource causes some action, then you (and the site) have fallen victim to a CSRF attack.

To answer your question directly: no, you do not need to have an example.com page open; you only need to have a valid example.com session token in your cookies.


Citations for Least Privilege network services? The Principal of Least Privilege suggests that network services should not run with powerful and unnecessary capabilities.  History teaches us that this is painfully necessary; 25 years ago Sendmail and BIND ran as root, and shifted to run as non-privileged users to limit the damage demonstrated by numerous buffer overflows and other attacks.  Alternative mail servers like Postfix and qmail were foundationally designed to run as non-root users, and the user context of Apache was an item on every checklist I've ever seen to secure Apache.

However, running a service as root is not a vulnerability per se; to quote OWASP,

  The failure to drop system privileges when it is reasonable to do so
  is not a vulnerability by itself. It does, however, serve to
  significantly increase the Severity of other vulnerabilities.

So, for example, there's no OWASP Top Ten saying "Don't run services as root."  Just other issues (like 2004-A5 "Buffer Overflows") whose impact is made more severe if the service is run as root.

Which makes it difficult to convince non-Security personnel that this is a Bad Thing.

So my question:

Can you point me to any cite-able references from reputable authorities that can be used to impress upon non-Security personnel (e.g. developers, IT, management) the importance of not running services with root privileges?

Not sure which kind of reference you're looking for, but The Principle of Least Privilege was first enunciated by Saltzer and Schroeder in their 1974 paper "The Protection of Information in Computer Systems":

  Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.

(Saltzer, Jerome H. (1974). "Protection and the control of information sharing in multics". Communications of the ACM 17 (7): 389. doi:10.1145/361011.361067. ISSN 0001-0782.)

The full paper can be read here.

That should be a valid enough reference.


Is allowing unfiltered curl request from a website a vulnerability? Recently I was on a website which provided some non-sense feature:

Enter a URL
Press enter
HTML source  of a given URL is displayed

It basically fetched a URL  and just dumped the contents of it. It could be XML, txt, HTML,  any reachable path via curl.

Now it struck me that this should be quite dangerous, am I right?

I have no Linux at hand and I could not find this site but a quickly hacked PHP page on my Windows machine happily consumed the URL:

file://D:/something/index.html

and presented it to me. Wouldn't this basically allow an attacker to roam the machine the script is running on? Would this URL

file:///etc/passwd

work on linux?

Is there some other obvious issues with that?

Impersonating someone else accessing other resources via schemes like POP3, LDAP, smb?

While writing this I asked myself whether white-listing schemes to HTTP[S] and maybe FTP would fix those issues?

I still would be able to impersonate a visitor on a site via this page but I am not aware of any issues except visiting illegal content or probably bypass things like censoring.

If the input is not carefully filtered, then that is a vulnerability called Server Side Request Forgery (SSRF).

There is even a common weakness enumeration number and page for it.
https://cwe.mitre.org/data/definitions/918.html

  By providing URLs to unexpected hosts or ports, attackers can make it
  appear that the server is sending the request, possibly bypassing
  access controls such as firewalls that prevent the attackers from
  accessing the URLs directly. The server can be used as a proxy to
  conduct port scanning of hosts in internal networks, use other URLs
  such as that can access documents on the system (using file://), or
  use other protocols such as gopher:// or tftp://, which may provide
  greater control over the contents of requests.

By exploiting this vulnerability an attacker can:

Scan hosts from the server's internal network that is not normally accessible
Enumerate and attack services that are running on these hosts
Exploit trust relationships which the vulnerable server might have
Proxy HTTP traffic through the vulnerable server which will mask the source of the traffic

Unfiltered cURL support is even worse than a normal SSRF vulnerability because cURL supports many URL schemas besides HTTP and HTTPS. Run #curl-config --protocols to see what is supported.

You can access local files with the file:// URL scheme (curl file:///etc/passwd does work on linux)
It’s possible to use the dict:// URL schema to make requests to any host on any port and send custom data. The URL dict://host:port/command will cause the server to connect to a host and send the string command to the specified port.
Access different services:

ldap://
ftp://
scp://
smb://
telnet://
imap://
pop3://
smtp://
rtsp://
tftp://


How does RealVNC Enterprise Know My System Credential? After the installation of RealVNC on a Windows computer, the default login username and password via VNC is the same as the system username and password. Can anyone tell me how RealVNC can access such information? Isn't such information supposed to be encrypted and unaccessible except Windows?

It does NOT. Allowing you to login using your system credentials does not necessarily mean that RealVNC knows them. It means RealVNC asks the OS to do the authentication for it. Your password is never saved on your hard drive and even your OS is not aware of it, it's the hash of your password that is saved and used to verify that you are who you claim to be. The hash can't be reversed and your password can't be retrieved by RealVNC or any other program.


gstatic.com resolves to local isp In the light of Snowden revelations I become very paranoid. Yesterday I did a netstat -t -p and from my browser there were several connections pointing to my isp. I had only 2 pages open.

Trying to find source of the connection, pinged all urls that the browser connected to.

gstatic.com was pointing to one of my isp ip. Did a dig all A section was full of ips from my isp. Is that normal ?

This is absolutely normal. gstatic.com is used for static Google content (Javascript, pictures, CSS, stuff like that which is the same for all users), and one advantage of offloading static content onto its own domain is that they can then use a CDN to put that content as close as possible to users. So, Google puts copies of the content on servers in your ISP's datacenter in order to speed up page loads.


Security of Signal download records What about the security of names of people who download the secure messaging apps Signal? Is there some master list that Signal keeps of every subscriber, that they could be forced to share, or could be hacked?

In theory, using secure apps simply identifies people sending potential sensitive information.

I've read here that "[Open Whisper Systems founder Moxie Marlinspike says] that [Signal doesn't] publish statistics about how many users they have, but Android’s Google Play store reports that Signal has been downloaded between 1 and 5 million times. The iPhone App Store does not publish this data."

So the iPhone App Store does not publish this data, but this does not indicate whether they record the data or not.

App stores (both Google and Apple), ISPs, and Open Whisper Systems could probably all identify Signal users if legal compelled / hacked. Not sure who could legally acquire this information, and the value / quality of it (downloading an app is not the same as using the app). If you want something where you can blend into the crowd more, try WhatsApp; it's the same protocol. Though WhatsApp likely store more meta-data. Ricochet, if used properly, can be very difficult to attribute, but is far less convenient.


Strict Transport Security -- max_age value I've been wondering what max-age should the HTTP Strict Transport Security header have.

Both paypal and lastpass sites leave it very low: 500 (seconds = bit over 8 minutes)

market.android.com has it set much higher: 2592000 (seconds = 30 days).

Do I correctly guess that the value should be at least few days? Doesn't a 8-minute timeout defeat its purpose? Are there any other downsides apart from privacy concerns (you can check during the next month if someone visited particular page by looking at a browser cache)?

From the IETF draft [ http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06 ]:

  10.1 HSTS Policy expiration time considerations

  Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, e.g., by constantly sending the same max-age value to UAs.

  For example, a max-age value of 778000 is 90 days:

Strict-Transport-Security: max-age=778000

  Note that each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host. The specifics of how this is accomplished is out of the scope of this specification.

  Or, whether they are setting an expiry time that is a fixed point in time, e.g., by sending max-age values that represent the remaining time until the expiry time.

  A consideration here is whether a deployer wishes to have the signaled HSTS Policy expiry time match that for the web site's domain certificate.

  Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to wilfully set max-age in order to have UAs enforce the HSTS Policy for their host, and protects them from inadvertently enabling HSTS with some arbitrary non-zero duration.

Therefore, since the browser will update it's stored HSTS max-age on every max-age header recieved [over https], going with the longer time won't really cause any of this bad cache horror story that the gossip talks about. The only issue is if the cert changes. However, site owners should be aware of this and should have the max-age set low (5-8 minutes) right before (a full day or so) the cert change is done due to expiration. However, this is only to deal with an incoming cert expiration (which is mostly avoided by replacing the cert with a new one before the last minute), as can be seen by:

  14.6 Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack

  If an attacker can convince users of, say, https://bank.example.com (which is protected by HSTS Policy), to install their own version of a root CA certificate purporting to be bank.example.com's CA, e.g., via a phishing email message with a link to such a certificate. Then, if they can perform an attack on the users' DNS, (e.g., via cache poisoning) and turn on HSTS Policy for their fake bank.example.com site, then they have themselves some new users.

Which shows that cert change in the middle of a broswer's HSTS "session" would not cause problems unless there were problems with the cert (validation warnings or errors). This would render the whole point of your question moot because it assumes that browsers store some piece of information related to the cert sent with the HSTS header response to validate against the HSTS host. As the draft makes no mention of such a concept, I would say that it is an invalid assumption.

However, storing cert information to be used against HSTS hosts can be done with public key pinning. But this would be done at a "factory" level or by the user manually, and as such would also have no way of updating via a HSTS host. [see http://www.imperialviolet.org/2011/05/04/pinning.html for more information]

To answer your last question, there is a privacy concern in the use of HSTS to track users. It works by using javascript to check if a resource in a list of websites that is enumerated through is loaded via https even though it is specified as http. The point of having a moderately low max-age in this case would be to have the entries cleared so that user tracking would be hindered. [see http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-privacy/ for more information]

@Jesper Mortensen: HSTS causes the browser to rewrite all http requests to https before sending them. Therefore you shouldn't have both http and https accesses to a given domain. And anyone implementing HSTS SHOULD (RFC2119) not have a real http facing site (ie redirect on http requests to https via 301 or do something else [see section 6.2]). And mixed context stuff (http to other non-ssl non-hsts domain resources are a problem that is supposed to be dealt with on an implementer basis (by both server and browser)). Also try not to mock its draft status as it is implemented in both Firefox and Google Chrome(ium) [ie. ~55% of all browsers].


Trying to prevent Cisco toll fraud A little back story on the setup first; We have a Cisco VoIP setup at our remote office(where I'm at) and the main CCM/CCX/Unity setup is at the parent company across the US in Connecticut. We have MPLS tunneling the VoIP traffic between the two offices. Very inefficient, but that's the cheap solution they went with to avoid the extra licensing of a second CCM/CCX. Also no one at the company works on the phone system, it is all outsourced to a third party, which stopped responding to my pleas for help a month or so ago.

Anyways, the way it works now, is if you call our 800# it goes to the main Auto-Attendant in Connecticut, and then is routed to our office, with 4 digit dial. If you call our local direct number, it rings through to the receptionist.

So the problem that I need your help with is; I am under a constant attack on my local #. If I leave my phone line plugged in to my VoIP router after 3:30, I will have upwards of 1000 voice mail messages in the morning by 7 am. It basically continues to try and bounce it's calls through our system until the voice mail box is full. I tried working with the tech company managing the system, and they basically came to the conclusion that we need to change our number or unplug the line every night.

The phone company also doesn't seem to know what to do either, I worked with a senior-level tech for a few hours, and he said the return field was being randomly generated/spoofed for each call that came through, so there was really no way for them to block them either.

The messages are usually just a minute or two of "Beep..Beep..Beep..Beep," and also hardly occur at all during the day.

Is there any hope at getting this resolved other than changing the phone number?

If you suspect a local device such as a fax machine being unintentionally forwarded, change the id of the device.
If you can recall when this first started, it may shed some light on this.
I would look for teleconferencing voip equipment as well.
Why was this listed as fraud -- did you have prior issues with fraudulent calls?
Do you have any disgruntled employees leave the company?
Changing vendors due to inadequate support or to an SLA issue is enough to get out if your contract. Sounds like the best way to go if you are remaining calm and collected when dealing with their tech support, etc.
   Hope that helps...


How to share EV Code Signing Certificate with USB token with other developers? I got the Extended Validation Code Signing Certificate from Global Sign
https://www.globalsign.com/en/code-signing-certificate/

They sent over a USB Token which I installed the certificate to ... or that's what I think I did.

My question is (how) can remote developers use that certificate or is the signing now limited exclusively to my machine / USB?

Any help is appreciated. Thanks.

To sign, you need the private key and the cert. It sounds like the private key is on the USB, but I can't be sure.

Best practices is to keep the private key, well, to keep it very private. It is generally only stored on a single machine and an automated workflow is used to copy binaries to that machine for signing. That machine should be as vanilla as possible to reduce the chance that it is vulnerable to an attack.

The reason for such care is that malware authors really like to get their malware signed with a valid, trusted code signing key. There's a famous case where, despite very strong security, Adobe's private key was used to sign malware. Now Adobe's code signing key is much more attractive to an attacker than yours due to the fact that many people have already told their computer to trust Adobe's key, but basic security practices such as those described above are still appropriate. Remember that it is your company's reputation at stake if you end up signing malware with your key.


Is it risky to report a security issue to a company or organization via non-dedicated channels? I recently visited the website for a large, reputable company which serves a malicious script (it's a knockoff of one of the major analytics apps, with an inconspicuous, intentional typo in the source URL). Additionally, the company serves a niche market, and likely doesn't have a large tech team, so their website hadn't been set up with HTTPS.

Fortunately, my antimalware software blocked the script, so I decided to look around at least the landing page to see if there's some kind of administrative (or even support) contact.

Not having found one, and not having found anything useful after doing a WHOIS query, I noticed that they accept Facebook messages via their official page.

Is it generally risky to notify a company of a vulnerability using such unofficial channels?

It turns out that in this instance, contacting them over unofficial means (Facebook private messaging) resulted in a response within about 48 hours followed by a quick patch to remove the injected script.

I can't provide a general, non-anecdotal answer to this question, though.


Sending messages using OTR & and GPG -- is it detectable? If I send messages using OTR & GPG, will my ISP or some surveillance agencies know that I'm using them? "Look, he's sending an encrypted message. He must have some important secret. Let's go rubber-hose him!"

Note:

Obviously, if they see the content of my messages (e.g. emails), they will know that they are encrypted. But I'm not sure whether they can do that or not. So let's suppose they can't see the content (and perhaps they can only see the traffic).

The simple answer is yes - your ISP can very easily see that you are sending an encrypted message. In many countries this is not an issue for two reasons:

most of the major webmail providers now use SSL so everything is encrypted
there would be too much data for the ISP to sift through it all, so they target specific threats (if you are one of those threats then sorry, your data is theirs...)

I understand that you feel like the ISP could target you, or that using encryption will make you stand out from the crowd, so there are ways to make encryption less obvious - however they are more effort:

ASCII Armouring as carried out by GPG leaves a header and footer describing the encryption used, but you could remove this if you wanted. The problem is that the data sent still looks like a large block of random data...which is still probably suspicious to your ISP
Translate every word you want to send into another word (using a one time pad if necessary) - then your message will be made of words, so probably won't trigger any filter looking for encryption (however a human interceptor reading it might get suspicious)

Your activity should be based around your threat model:

Are you a target for your ISP to waste effort on?
If not, would using encryption make you stand out from the crowd enough that you become a target?
etc


Reversible password storage obfuscation method for third-party login credentials I have an internal business application, that as part of its functionality connects to a third-party app using login credentials specific to the user of my own app. These passwords are stored in a central database. Currently they are plain text (this was justified based on a high level of front-line security into our corporate LAN), but a recent attack against the network of our new parent company (luckily they didn't actually get in) has led me to take another hard look at that.

Passwords for the main internal app, we can bcrypt them with a salt, no problems there. The problem is ciphering the third-party application credentials. As we all know, users like to keep the same password for multiple apps, so no matter what I do to the internal app password for safekeeping, it won't make a lick of difference if the third-party credentials are sitting there in plaintext right next to it.

Here's the kicker; whatever method is used, it must be reversible within the application, because the #$%^&* third-party app requires transmission of plaintext credentials from the internal app's process to a SOAP service (luckily it does so over HTTPS), and the internal application allows users to maintain these stored third-party credentials (saving the Dev department the trouble of maintaining DB content). So, the best I can do is encryption, not hashing.

So, I realize that any method I employ here will be less than ideal; if the attacker gets both the application and the credentials, he'll get the plaintext passwords and there isn't much I can think of to prevent it. I'm just trying to make an attacker work just that little bit harder to get the credentials, hopefully giving me enough time to at least alert the third party so they can disable our logins, if not force every user in the system to change their third-party credentials before the attacker can crack one.

So, what do you suggest? AES (I can't imagine RSA being of much use as the application has to both encrypt and decrypt)? Any clever tricks for keeping the key out of the hands of someone who manages to get both the DB and the application binaries?

Let's suppose that in your app (let's call it App1), the user already has to enter some credentials C1 (name and password) which App1 uses when it connects to your central database. Right now, your central database contains C2 as cleartext, to be used when App1 connects to App2.

Let H() be a hash function with a large output, say SHA-512. When the user enters his password (C1) in the interface of App1, App1 computes H(C1) and obtains a 512-bit value, which it then splits into two 256-bit halves, Pl and Pr.

The credentials C2 are symmetrically encrypted with a key derived from Pl. This derivation should be slow (like bcrypt or PBKDF2 or something equivalent); I suggest relying on an existing, well-audited format for the encryption details and the key derivation, e.g. OpenPGP. Let's call E(C2) the encryption result.

Now let your central database store E(C2) and bcrypt(Pr).

When the user enters C1 in App1, App1 applies H() to obtain Pl and Pr. App1 then contacts the central database and sends Pr (within a SSL tunnel, of course). The central database applies bcrypt() on Pr to see if that matches the stored value; if yes, it sends E(C2) back to the client. Then, App1 uses Pl to decrypt the blob and obtain C2.

This way, the central database never obtains the decrypted C2 at all; and C2 are known to App1 only in a transient way (in RAM, not "hidden" in the code). What the central database knows is sufficient to test a password for validity, but slow hashing and salting is employed to counteract that issue (as part of E() for Pl, using bcrypt() for Pr).


Do I need dedicated firewall? I have two servers in the datacenter.

FreeBSD <--> Windows Server

FreeBSD configured as a gateway for Windows Server.

What is the best:

FreeBSD has only firewall. All services are on the Win Server machine (e.g. firewall on FreeBSD, mail, web server on Windows Server)
Services are on the both servers (e.g. mail/firewall on FreeBSD, web server on WinServer)

As a general rule of thumb, running other services on security-related devices such as firewalls should be kept to a minimum. In other words, a firewall should ideally only be a firewall, and nothing else. The more services you run, the more likely one of them will contain a vulnerability that can allow an attacker to take over the machine. If that machine happens to be a firewall, it will make it much easier to compromise the rest of the network.


Security implications of using long lasting authentication cookies I'm trying to find some information about potential security risks with allowing long lasting cookies for website authentication.

Initially it was set to not persist the login session, so it would only last until the browser was closed. However we've recently changed it to persist for a couple of weeks.

I can see how it would be convenient for users to not have to re-authenticate frequently, but are there fundamental security issues with having the sessions last for perhaps a couple of months instead of weeks? Does a longer expiry for a cookie increase the chances of it being somehow compromised?

By limiting the time an authentication cookie is valid you are also limiting the time an attacker has access to an account if he/she manages to steal said cookie (given that there are no other countermeasures in place).

It also limits the amount of time an unauthorized person can access said account on e.g. a shared system in case the victim forgot to logout.

So if there are appropriate countermeasures against session hijacking and similar attacks, longer (unlimited) cookie lifespans should not be a problem.


How to find files accessible on external network? It was recently brought to my attention that there was a zip file containing a database backup accessible on my external network.

Is there a tool that will scan my external ips and return files that are accessible?

You could try with ENT (Essential NetTools) or a similar Utility to do a shared-resource scan from outside your Network and see what it finds.


For a "normal" computer user, does it make a difference to have a good entropy source? Let's take, for example, Linux. From my understanding, there are different sources and different ways that can be used to gather entropy (RNG daemon, Intel rrandr, TPM, etc). Some produce entropy that is of "better quality" than others. But, does it actually matter for a "normal" user?

(Let's say a user that only uses web browsers, office programs, and a password manager).

In which cases does the computer use entropy from the pool?

Does it uses it when browsing https websites?
Does it uses it when encrypting a file with 7zip or with a password manager?

For most cases, randomness quality is overrated.

Yes, it's important, can lead to some nasty consequences if done wrong, but there are so many easier mistakes that random quality would be at the end of your list of worries:

OS bugs
Browser bugs
Bad WiFi password
Password reuse
Default or hard-coded router passwords

The list is long. If you are affected by one of those, you lose. Exploiting the RNG to steal information is impractical if the attacker can exploit one of those issues. Breaking the RNG should be the last resort.

You must calculate the price to protect versus the information value. The attacker does the same. If you are not using the imperfect PRNG to protect something very valuable, you are good to go. Don't use it to generate a bank certificate, a Bitcoin wallet with a lot of coins, things like that.

Protecting a 7zip file or navigating using HTTPS will not be much more secure if you use a built-in PRNG or CloudFlare Lava Lamp RNG.


Is it possible to sniff MAC addresses from a client that is not connected to an AP? A similar question was answered here for sniffing MAC addresses from clients connected to 802.11 wireless access points. My question is, is it possible to sniff MAC addresses from clients which are currently not connected an access point? For example, does an active WiFi on a smartphone or PC broadcast its MAC address when it is searching for access points, or is it only in receiving mode?

802.11 devices send probe requests to identify if a given network is nearby. Probe requests still contain standard MAC headers - which would contain destination and sender address fields. The destination address would be set to the broadcast address ("ff:ff:ff:ff:ff:ff") but yes in normal client operation you would expect the client to fill their own address into the sender address field.


Security benefit of browsers automatically rewriting HTTP to HTTPS? I often use a guest WiFi which does the usual intercept; attempt to navigate to any HTTP website and it redirects you to the "Agree to our ToS" page, after which it will permit any traffic from your MAC address in the normal way.

Usually I just pick any web page and hit reload, but this WiFi does not like https://.  The query must be http://.

OK, so I go into the address bar and delete the "s" from HTTPS, and hit "go".  E.G. http://www.amazon.com/usual-Amazon-URL-here

And then my local browser puts the "s" back.  It makes the query on port 443, which the guest WiFi blocks.  It has to be the local browser doing this, since it has literally no Internet.  I can vouch for this occurring on Amazon's Silk browser, Firefox on Android, and I believe Safari/iOS.

Is this a policy of web browser clients to force to HTTPS anytime the browser knows the site supports HTTPS?  What threat does that defend against?

I suggest you look into NeverSSL, a simple site which will always be served over plain HTTP.

If you are sure it is your browser doing it and not a redirect on the server side, it is likely the result of a security feature called HTTP Strict Transport Security (HSTS). When a website wants to only serve over an encrypted connection, it sets an HTTP header that instructs the browser to only ever connect over TLS. Some sites may even use HSTS preloading, where the redirection policy is hardcoded into the browsers by default, rather than being set via an HTTP header over the network. HSTS of all kinds is designed to defeat MITM attacks that exploit the fact that your browser would be perfectly happy to stay on the non-encrypted version of a site, even if HTTPS is available. According to Security Headers, Amazon uses HSTS. This explains why you are being redirected.


Is Linux getting less or more secure? The famous so-called virus-and-hacker-free Mac is a thing of the past: As it gets more popular it gets more vulnerabilities. Will Linux be the same at some point in time? Is it getting less of more secure?

No computer or network system is 100 percent secure. There is always a vulnerability in every system.

Benefits of open-source security

  More people can inspect the source code to find and fix a possible vulnerability. This can lead to both faster discovery of unintentional
  security vulnerabilites and prevention of intentional vulnerabilites
  (backdoors) in the code put there by the developers themselves.
  Proprietary software forces the user to accept the level of security that the software vendor is willing to deliver and to accept
  the rate that patches and updates are released.
  The end-user of open-source code has the ability to change and modify source to implement any extra "features" of security they may
  wish for a specific use, which can extend to the kernel level if they
  so wish.
  It is assumed that any compiler that is used creates code that can be trusted, but it has been demonstrated by Ken Thompson that a
  compiler can be subverted using an eponymous Thompson hack to create
  faulty executables that are unwittingly produced by a well-intentioned
  developer. With access to the source code for the compiler, the
  developer has at least the ability to discover if there is any
  mal-intention.
  Kerckhoffs' principle is based on the idea that an enemy can steal a secure military system and not be able to compromise the
  information. His ideas were the basis for many modern security
  practices, and followed that security through obscurity is a bad
  practice.

https://en.wikipedia.org/wiki/Open-source_software_security

Eventually the point is; if I can read it, I can find it. I can find the mistakes and malicious code lines in any kind of computer program "easily". That means open-source is more secure than closed source.

  The development of Linux is one of the most prominent examples of free
  and open-source software collaboration.

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


Does it make sense to choose a longer password than the output of a hash? Let's take MD5 for example:

It outputs a 128-bit hash. Does it make sense (in theory) to choose an input (password) which is itself longer than 128-bit?

Does it increase the probability of a collision in any way?

I know that MD5 is broken, so what about more modern algorithms like bcrypt or scrypt?

If you consider a set of potential passwords of size P, with a hash function with N possible output values, then the probability that there exists at least one collision in this set is quite low when P is less than the square root of N, and quite high beyond. See the birthday problem. As the Wikipedia page says, that probability is approximately equal to 1-e-P2/2·N.

With figures: if you use passwords consisting of 10 characters (uppercase letters, lowercase letters and digits), then P = 6210 = 839299365868340224; with a 128-bit hash function, N = 2128. The formula above means that there may exist at least one colliding pair among all these passwords with probability close to 0.1%. On the other hand, if you add one character to your passwords (i.e. the potential passwords have length 11, not 10), then the probability that there exists at least one collision rises to 98.1%.

Now all of this is about the probability of existence of a collision; not probability of hitting a collision.

Collisions are not relevant to password hashing. Password hashing works on preimage resistance: given the hash, how hard or easy it is to guess a corresponding password. Note that I said "a", not "the": for the attacker, it does not matter whether he finds the same password as the user did choose; he just wants a password which grants access, and any password which matches the hash output will do the trick.

Note that while MD5 is "broken" for collisions, it is not so for preimages (well, for preimages it is "slightly dented", but not significantly for the purposes of this question).

There are two ways to break preimage resistance:

Guess the password. This means trying all potential passwords until a/the right one is found. If there are P possible passwords with uniform probability, then this has cost at most P/2 because the user did choose one of the passwords, and the attacker will need, on average, to try half of them before hitting that exact password.
Get lucky. Try passwords (random, consecutive... it does not matter) until a matching hash value is found. This has average cost N/2.

The password hashing strength will be no more than the lower of the two. In that sense, using a set of possible passwords which is larger than the output of the hash function (e.g. P > 2128 for a 128-bit hash function) does not bring additional security, because beyond that point, the "get lucky" attack becomes a better bargain for the attacker than the "guess the password" attack, and the "get lucky" attack does not depend on how the user actually chooses his password. Please note that I say "size of the set of passwords" and NOT "password length". All the analysis above is based on how many password values could have been chosen, with uniform probability. If you use only 200-letter passwords, but you may only choose ten thousands of them (e.g. because each "password" is a sentence from your favourite book, and the attacker knows that book), then the size of the set of potential passwords is 10000, not 62200.

In practice, P is bounded by the user's brain (the user has to remember the password) and is invariably lower than N. A "very strong" password is a password from a selection process which uses a P of 280 or more; that's sufficient for security, and yet far below the 2128 of MD5 or the 2192 of bcrypt. But it seems unrealistic to expect average users to choose very strong passwords on average. Instead, we must cope with weak passwords, with P around 230 or so (meaning: try one billion possible passwords, and you'll have broken the passwords of half your users). Mitigation measures are then slow hashing (make each guess expensive) and salts (don't allow the attacker to parallel-attack several passwords at reduced cost). See this answer.


Security at writing in a folder I would like to run with Runtime.exec() programs in Java (the programs' code are in C and Java ) - the users are uploading the Java/C code, and my app runs them. The code is saved in a separate folder for each user, as well as the input and output files.

In case of C code, the compilation code is the following:

compileCommand = pathToMinGW + "gcc " + pathToFile + fileName + ".c -o " + pathToFile + fileName

And the command for run:

executeCommand = pathToFile + fileName + ".exe"

Running the command:

Runtime runtime = Runtime.getRuntime();
Process run = runtime.exec(executeCommand);

How can I give permissions for the exec() function, to let to modify the output files from the folder where the uploaded code is, but nothing other?

You create an isolated user first (e.g. with no groups on it),and you run another java instance from administrator (via windows service for example), were you push the commands in a queue, and you got a queue of error codes, in e.g. SQL DB.

And in Linux, you can run also Java from root, and make a queue of commands (with files in folder and SQL, and push the commands and receive the results via another queue).

And the Java instance running exe must run from root or administrator, to be able to run another exe with different user, so you dont need to reload java every time. In windows you would need to compile a binary doing this using windows Process, to launch external command via another user. In Linux you can use "su" or "sudo" commands to do it, so you can do:

[root@abcdef ~]# su - test -c "/usr/bin/id"
uid=503(test) gid=503(test) groups=503(test) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So your java would require access to the SQL with the queue, so this would be the easier way I suppose, I have did this way and I am so far not hacked.

ps. Queue has to be serialized and with timeout for each run.


BLS signature java implementation needed (if possible, along with some example code) I need to sign a string with the shortest digest possible using regular certificate like X.509. As far as I understand, I will have to transform the string to the sequence of bytes, then sign. After that I need to transform signature to the string also (so it can be passed from one human to another). I found out here that BLS algorithm is great for that and I want to try it out. Would you recommend some java implementation of it (would be great to have a code example along with that so I can avoid messing up with string to byte and vice versa transformings)?

The Boneh-Lynn-Shacham signature scheme works only in special elliptic curves that support efficient pairing computations. This is not something that you somehow add on top of an existing signature; it is a signature algorithm in its own right, that uses its own kind of public/private key pairs. If you want something that works with X.509, then you need a public key that can be encoded as part of an X.509 certificate. Currently, there is no defined format for a public key appropriate for BLS(*); X.509 is an open-ended standard so you could conceptually define your own format and make your own implementation, but:

This is an endeavour of considerable scope. It would require from you thorough knowledge of ASN.1 and DER encoding, elliptic curves, and pairings over elliptic curves (which is a plunge into rather hairy mathematics); and also strong skills at implementing cryptographic algorithms.
Since that would be your definition, there would be no interoperability with the implementation of anybody else, so your signatures would be verifiable only with your own software. At that point, why bother with X.509 at all ?

The advantage of BLS over a more common signature scheme, such as ECDSA, is that it produces shorter signatures. Shorter, not necessarily short. If you want n-bit security (traditionally, n = 128; current technological limit to the breakable is somewhere between 75 and 85), a BLS signature will need to have length at least 2n bits, while ECDSA requires 4n bits. Note that even with BLS, we are still talking about at least 200 bits or so, which is a lot for human-powered input. For instance, a Windows product key uses 25 characters taken in a 24-sign alphabet, which is sufficient to encode up to 114 bits, no more (because 2425 is approximately equal to 2114). If you want human users to type signature values, then even with BLS you are considering an effort similar to entering two product keys (four product keys with ECDSA). In most contexts this is probably too much to ask (indeed, if you could ask for more, then Microsoft would also do it and use longer product keys, precisely so that they could use cryptographic signatures like BLS...).

If you still want to delve into BLS, then start with the PBC library. It is written in C, but the conversion C-to-Java is the least of your worries -- understanding the usage context and the maths is a lot harder. I am not aware of any openly available Java implementation of pairings, but it is absolutely doable (I can guarantee that, because at one point I wrote a pure Java implementation of pairings). Depending on your existing knowledge in maths, crypto and development, obtaining a functional, reasonably secure implementation could take you several years of full-time work. Personally, I have already done that once, so I know all the maths and crypto, and I have done a lot of crypto implementation in Java, and it would still take me at least two or three weeks of full-time work to produce something that could be described as "decent".

Edit: actually a simple Google search with terms "BLS signature java" uncovers jPBC, which appears to be a Java port of PBC. All my points about the need to understand the maths, and the interoperability issues, still hold.

(*) It is possible to encode a BLS public key using the generic format for elliptic curve public keys, but that format does not include any field to notify decoders that the curve is appropriate for any specific kind of pairing. Even if the software receiving that key can recompute the embedding degree, there is no way to indicate the pairing type to use (Weil, Tate, any distortion map...).


Does adding random noise and/or resizing images help neutralize graphics files with embedded exploits I've sometimes heard/read that one of the ways to deal with embedded  exploits (malware code built into the image encoding itself) is adding random noise to an image file, or resizing the image. Are any of these methods in fact helpful?

As a very simple (non-exhaustive) example, something like this where javascript is injected into the image encoding section of a gif to execute an xss attack.

I've already checked this security.se question which has useful info but not exactly what I'm asking here.

It depends. The specific example you gave is for an XSS exploit, which is not an exploit of image viewers or decoders. Modifying such an image may destroy the malicious code, depending on the kind of exploit. If the image is corrupt such that it will exploit an image viewer, editing the image in any way (including resizing it) will very likely pass it through the same vulnerable decoder (e.g. libpng) as the one used by an image viewer. Consider this simplified view of how an image editor works:

A source image is passed through a decoder which converts it into a pixel map.
Any modifications to the image are made to this raw pixel map, in memory.
The pixel map is compressed and converted into a standard image format.

Now compare this to how an image viewer works:

A source image is passed through a decoder which converts it into a pixel map.
The pixel map is displayed directly on the screen.

The first step in both instances are the same. Unfortunately, this step is where the vulnerable image decoding library is affected. In many cases, modifying an image is actually worse because the decoders are often more complex in order to support a wider variety of obscure formats and features.


EMV choose crypto method between SDA/DDA/CDA I'm a newbie in emv world.
I'm trying to follow this flow:

I'm in the third step. I have to manage the Offline Data Authentication.
How can I negotiate the correct way (SDA, DDA or CDA) with the ICC to perform offline auth?

I got it.
You have to the AIP field as follows:

To retrieve the AIP, according to "EMV Book 3 - Application Specification", use te Tag 0x80 Format 1 reply for GET PROCESSING OPTIONS contained:
x82: Application Interchange Profile (AIP),
x94: Application File Locator (AFL).


Can I create an SSL certificate on windows signed with the machine's certificate? From MMC > Certificates I can see there's a certificate for the current machine under 'Trusted Root Certification Authorities > Certficates'. e.g. on my workstation called 'RoryWorkstation1' there's a certificate called 'RoryWorkstation1' listed along with all the normal ones like Baltimore, Microsoft Root Authority, Thawte, Verisign, etc. Can I use this machine certificate to generate an SSL certificate that I can use on the local machine? Clearly it'll only be trusted from the local machine, but for example I'll be able to make requests to https://localhost and the browser will treat that as trusted.

I'd prefer to do this than create a self-signed certificate and add it to the store as that adds it to a machine-wide store of valid certificates, so it's changing the machine state. I'm thinking of doing this in software running as a windows service on the machine and I'd prefer not to change the certificate stores because that seems more intrusive and there's a possibility it could be overridden by Group Policy or similar. Generating a certificate that I can then only use on the machine means I'm not changing the machine state itself. It would mean I end up with a certificate that I can only use within software running on the machine.

In my case the reason I want this is to be able to make https requests to https://localhost without hitting certificate errors. I could use another domain name and use HOSTS file to point at 127.0.0.1 but that could have problems with proxy servers and generally seems less transparent than finding a way to make https://localhost work.

No, you don't have the private key for that root to sign certificates.

However, as Julian suggested you could generate your own self signed certificate and then add it to your trusted store.

Assuming you're running Windows, this is how you add it to the trusted store:
http://blogs.technet.com/b/sbs/archive/2007/04/10/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista.aspx

This is how you can generate a self signed cert via IIS7:
http://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx

This is how you can generate a self signed cert via OpenSSL:
https://stackoverflow.com/questions/10175812/how-to-build-a-self-signed-certificate-with-openssl

Have you checked with your IT department to inquire about an internal Certificate Authority? If there is one, you can issue an SSL cert signed by your company's CA.


Preventing installation of VPN software on home computers? How can users be prevented from installing VPN software on their home computers?

I assume you want to prevent your employees from using their personal computers to access your work network via VPN.

You can't prevent them from installing VPN software on their home computers, but you can disallow VPN connections from systems using Posture Checking.

Posture Checking involves the VPN server querying the VPN client for information prior to allowing authentication to be attempted.  If the endpoint (client computer) doesn't meet the criteria for an allowed connection, then authentication and VPN connection are not allowed.

Posture Checking is one name, you may also see Posture Assessment, Endpoint Compliance, Endpoint Policy, etc. etc.

This can include (Cisco example):

  In the adaptive security appliance (ASA), you can create a prelogin
  policy that evaluates endpoint attributes such as operating system, IP
  address, registry entries, local certificates, and filenames. Based on
  the result of the prelogin policy’s evaluation, you can control which
  hosts are allowed to create a remote access connection to the security
  appliance.

and (Check Point example):

  The Endpoint Policy Management Software Blade allows you to enforce
  endpoint compliance on multiple checks before users log into the
  network.

  You can check that the:

  appropriate endpoint security software blades are installed
  correct OS service pack are installed on the endpoint
  only approved applications are able to run on the endpoint
  appropriate anti-malware product and version is running on the endpoint.

  Plus, set users to Observe, Warn,
  or Restrict access to the network if they are not compliant with the
  policy. Also, allows for automatic or user-based remediation.

Most commercial VPN systems will provide an equivalent functionality, sometimes bundled, sometimes for an additional cost.