Simple answer:  Not exploitable

Although it maybe possible to inject script code using a malformed HTTP verb, this attack vector is missing the "cross-site"  component which makes the vulnerability useful to an attacker.   So, why would an injection like this be useless to an attacker?

Well first of all how does an attacker send a "cross-site" request?  There are a couple of variants,  but the most common is as follows.

<form id="CSRF" method="POST"  action="http://victim/search" >
<type=hidden name=search value="<script>alert(1)</script>">
</form>
<script>
document.getElementById("CSRF").submit()
</script>

The HTML above will automatically send a POST request when the victim renders the HTML.  The page http://victim/search is reflecting the search POST request on the page,  thus executing the XSS payload in the victim's browser in the context of http://victim/search regardless of where the request originated from.

It is possible to control some of the HTTP header using flash, so I wrote a flash exploit framework to leverage unusual CSRF/XSS.  Unfortunately flash currently only permit the GET and POST verbs,  PUT and DELETE where allowed at once upon a time,  but no longer.


If your main objective is to ensure integrity and authenticity, and not confidentiality, it sounds like what you want is not encryption, but message authentication (symmetric, like HMAC) or a digital signature (asymmetric, like RSA).

Since you mention third parties, it's likely that signing with an asymmetric system should be used, since with a symmetric system the third parties would be aware of the key, and could impersonate the authentic sender (perhaps you).

Implementing (coding) RSA or AES even from the ground up isn't difficult per se, but it's difficult to do correctly. Use some well-known library or an application to do it. (For signatures, you could use e.g. GPG.)
RSA is (much) costlier to compute in terms of ciphertext bytes than AES, but the usual method is to use RSA to encrypt a symmetric key, and to encrypt the message with that. Or with signatures, to sign a hash of the message (instead of the message by itself).
For key sizes, a 128-bit AES key is considered to correspond approximately to a 3072-bit RSA key. 1024 bits for RSA is on the low end.


Do large companies use multiple public-private key pairs?

Websites use x509 certificates which uses public key cryptography (public private keypairs).

Even small companies have many different certificates, and many different public private key pairs. The idea is if one system is compromised and a private key is exposed, you wouldn't want to risk traffic on another system.

Think of it this way. Would a multinational company use the same lock with the same key on all their doors at all their facilities?  No way!  They have a different lock on every door.

There's so much to this topic, certificates, CAs, trust chains, etc. You may want to read up on how certificates and TLS works.

Companies will also use public key cryptography for logging onto computers, their email, and a myriad of other things.


Why do we still use keys to start cars? why not passwords?

Poor password choices

The primary threat that a car lock protects against is theft of the car or of objects inside the car. Most theft is opportunistic, not targeted: go to a parking lot, try multiple cars until you find a poorly protected one. With passwords or PIN, you know that many people are going to pick password or 1234 or for the more paranoid their date of birth. Locking a car after failed attempts doesn't matter: the thief will just try the three most likely values on each car then move on.

Additionally, force-locking the car after failed attempts would be annoying if your kid starts mashing the buttons.

Shoulder surfing

Typing a password is vulnerable to shoulder surfing. It's hard to duplicate a physical key solely from pictures (it can be done, but only with precise enough pictures). It's impossible for an unaided human to duplicate a physical key.

It's easy for an unaided human to remember the PIN they've just seen somebody type. Pass by someone in a parking lot, note the PIN, see them the next day/week around the same time, profit.

Loaning

I can loan my car keys to someone. When they give me back the key, I can be reasonably confident that they no longer have access to my car. Sure, they might have duplicated the keys, but that requires time (if they only borrow the car for a short time, I know they haven't done it), and if I trust them enough to loan my car, I probably trust them not to copy the keys.

If there's a single password to open the car, then if I let someone use my car, they have access forever.

This can be solved by having multiple passwords to open the car, of course. But that adds another set of difficulties. One is that the key space might need to be larger: with a small key space such as a 4-digit PIN, the probability of an uninformed guess can become non-negligible with multiple valid codes. A bigger difficulty is that this requires Joe Random to do key management. Joe Random's VCR blinks 12:00 since the last power failure. (Maybe not anymore with DVR that have an Internet connection.) Joe Random understands physical tokens — if I have the object in my hand, I control it — but not password management.


It turns out that the nameif identification of interfaces, which can be used to "name" a VTI cannot be used in NAT statements.  So, instead of being able to use source NAT like

  nat (inside,outside) source static (real_subnet) (translated subnet)

I have to use twice NAT with any,any statements like this

  nat(any,any) source static (real_subnet) (translated subnet) destination static (real_subnet) (translated subnet)


How to use NMap to portscan a SonicWall that is blocking all attemtps?

As far as I know, nmap in Stealth Scan mode issues a normal SYN packet, which should elicit a SYN/ACK response no matter what. The "stealthiness" comes later, when nmap receives the SYN/ACK and instead of acknowledging, tears down the connection with a RST, which prevents the connection being logged on some systems, and ensures it being logged and a We're being stealth scanned! alert triggered in others.

Try first with a vanilla connect scan: -sT instead of -sS. If that works (I don't see why it shouldn't, but then I'd have sworn -sS ought to have worked too), for one you now have "a means of scanning the system". And you can investigate how SonicWall detects the stealth SYN (I found nothing on SonicWall's docs), using something like Nemesis.

The packets are different though. The DF flag wouldn't be reliable on SonicWall's side, nor would the checksum (even if it's curious)... maybe the TCP window value is considered suspicious? Or the packet size?

The Vanilla and Telnet packets are so similar however, that if -sT does not work for you, I'd have to say that you must be doing something wrong.

Stealth Scan:

09:20:46.808358 IP (tos 0x0, ttl 41, id 24165, offset 0, flags [none], proto TCP (6), length 44)
    mintaka.33810 > darkstar.77: Flags [S], cksum 0x40ee (correct), seq 3935459869, win 1024, options [mss 1460], length 0
        0x0000:  4500 002c 5e65 0000 2906 a93e c0a8 04c8
        0x0010:  c0a8 0410 8412 004d ea92 5a1d 0000 0000
        0x0020:  6002 0400 40ee 0000 0204 05b4

Ordinary telnet:

09:21:14.865468 IP (tos 0x10, ttl 64, id 58002, offset 0, flags [DF], proto TCP (6), length 60)
    mintaka.50911 > darkstar.77: Flags [S], cksum 0x8a57 (incorrect -> 0x9259), seq 331969772, win 14600, options [mss 1460,sackOK,TS val 202741374 ecr 0,nop,wscale 7], length 0
        0x0000:  4510 003c e292 4000 4006 cdf0 c0a8 04c8
        0x0010:  c0a8 0410 c6df 004d 13c9 74ec 0000 0000
        0x0020:  a002 3908 8a57 0000 0204 05b4 0402 080a
        0x0030:  0c15 967e 0000 0000 0103 0307

Vanilla scan:

09:22:25.447135 IP (tos 0x0, ttl 64, id 57087, offset 0, flags [DF], proto TCP (6), length 60)
    mintaka.50912 > darkstar.77: Flags [S], cksum 0x8a57 (incorrect -> 0x8c7e), seq 1141769620, win 14600, options [mss 1460,sackOK,TS val 202759019 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c deff 4000 4006 d193 c0a8 04c8
        0x0010:  c0a8 0410 c6e0 004d 440e 0594 0000 0000
        0x0020:  a002 3908 8a57 0000 0204 05b4 0402 080a
        0x0030:  0c15 db6b 0000 0000 0103 0307


Before trying to convince them that their policy is restricting your requirements, first find out why they have this policy in place.

I have worked with companies in the past with similar requirements, and it can be a pain, but when you consider the risks of a locally hosted SQL server (backup requirements, licensing requirements, risk of an insecure and untested front end, patching and maintenance issues) it makes more sense to have them hosted in a central location with dedicated personnel.

I know this maybe isn't the answer that you are looking for, but it is much easier to work with a company policy when you understand the reason for it existing.


Is it bad if session key is passed in plain text in URL?

Also what's the difference between a session key and session value?

There are basically two ways to maintain information about a session:

Put the information into the database and associate these with some unguessable (i.e. random) key. Use this key inside some cookie or similar when communicating with the client. Lookup the information based on this key whenever you need these. In this case you have a session key (cookie) and session value (information in database).
Encode all information into some string and protect this session token against manipulation and guessing. In this case you have no value in the database but can extract all information from the token.

  .. dangerous to put the session key in the URL because it could be cached, either by the browser or a proxy etc. Is this correct?

Since the session key is often used to identify a logged in user it should be treated like a temporary password, i.e. it should be treated as secret. This means it should be protected with HTTPS against sniffing. This means also that it should not be logged because somebody might get access to the logfiles even without hacking which usually contain the full URL. And it should not be forwarded to a third party, i.e. neither automatically with the HTTP Referer header nor manually by the user when sharing the current URL.


To summarize the checks that can be done in order to assess wheather and how the account has been compromised:

First of all see if the files in question are shared with other users (which may be the cause of the problem). Someone who might have had full access to the account might have granted himself access and now is still able to modify the files after losing the login credentials thanks to your intervention. Also the user might have accidentally shared a folder or more with a wrong user.
See which applications have access to the account on the permissions page, look for suspicioius ones and, in the best case revoke access for all, for now at least.
See any API access tokens have been created or are currently active. A list of which should be in the Developers Console under: Developers Console/apis/credentials
In addition you can look at the security log
Finally, of course, the user's computer itself or one of those having access to a share might be compromised or the users themselves may be involved.


Should I be worried about SQL Injection for Internal Web Apps?

Protections are in place to address risk - protections have a cost (time/effort to code, in your case) and those costs need to be compared to the benefits/costs of implementing them. If the cost of the realized risk is lower than the cost to implement protections, then it doesn't make sense to to implement protections.


Grey vs Green padlock in address bar - technical difference

In Firefox, a grey padlock indicates that the site in question does not use an EV certificate. Sites using EV certificates shows up as a green padlock.

There is mostly no practical difference between the two types of certificates. Both are equally secure from a technical POV. For a more thorough answer about EV certificates, see What are the advantages of EV Certificate?


A magic link alone is not necessarily bad. A 512 bit entirely random value is going to be no easier to guess than a 512 bit private key. In general it is considered good practice to expire them after a reasonable amount of time. A good approach - which also avoids having to store database entries is to embed the token data in the url and sign it with a private key. I.e.

site.com/login?type=login&user=[username]&expires=[datetime]&sig=[signature of other parameters].

However email as a transmission mechanism isn't secure.

By default SMTP offers very little protection against interception. Traffic may be encrypted between servers but there are no guarantees. Even with encryption its still often possible to man in the middle the connection (encryption is not the same as authentication).

  If so, then how is sending a link for password reset any more secure?

It isn't. This is why several services ask for some additional proof its you before sending the link (or after clicking it).


Searching vulnerabilities via similar code comparison. Is it a viable attack vector?

In theory, yes, this is possible and there have been some attempts to do this. However, the technique is not all that practical because there are just too many variables involved to generalise the approach. What your talking about is really just a subset of static code anlsysis and it has been used for along time. The problem is, it has a lot of limitations

It is usually language specific. Trying to develop a solution for all software code is too complex
You often need to work at the AST level to eliminate variable names, code style etc. You need high level abstracted representations, which akes it slow
It can be difficult to identify issues which are not closely located in the code. for example, a security hole may only exist if there is a set of preconditions spread over multiple code file or modules
It often gives large numbers of false positives which need to be manually verified.

Having said all of that, there are a number of static analysis tools which can help narrow the search space for potential security holes. These often focus on a specific type of security issue, such as SQL injection or XSS vulnerabilities and are usually restricted to a specific language. Many of the better ones are very expensive.

The potential for such analysis has certainly increased due to the growth in available repositories, such as github. Defining exactly the scope to use can also mean such approaches can be beneficial. This is especially the case due to the growth in the use of open source libraries and frameworks. For example, if you know of a vulnerability in a popular library or framework, it isn't too difficult to identify code which uses those frameworks or ibraries as possible candidates for more intensive search. Likewise, the growth in the use of 'cut n paste' style programming may have some potential - if you find a popular example of how to implement some pattern/algorithm which has a flaw, you may be able to find that pattern in public repositories etc.

This type of static analysis won't automate the process, but it certainly could help in reducing the search space for code with security problems. However, at the end of the day, it will normally require someone to take the results and perform manual analysis and inspection.


Is a SHA checksum enough to verify integrity and authenticity?

You're conflating two things, which is why you are confused about them. Let's pick both HTTPS and SHA-512 apart and then things will be much clearer.
What does a hash offer me?
A hash algorithm is a way for a program to take some arbitrarily large input and return a (usually small) fixed output. For example, a program can have several GB of data, but the output of the hash algorithm with that program as input is still 512 bit long.
This makes it very easy to check whether or not two files are identical, without checking every bit of the message itself (since that is essentially the same as transmitting the message itself again).
As such, if you downloaded a file and the hash of that file, you can calculate the hash yourself and then compare it to the file. You can be reasonably sure1 that the file is the same as the original if the hashes match.
However, this alone doesn't generate any authenticity. You can't know who generated the hash, or who published it.
What does HTTPS offer me?
HTTPS is based on TLS, which in turn uses different ciphers to satisfy confidentiality (nobody else can read your data), integrity (nobody else can modify your data) and authenticity (the source of the data is who you believe it is).
As you may expect, these ciphers use hash algorithms like SHA-1 or better yet SHA-2 to verify integrity. Public Key Cryptography such as RSA are used to authenticate the client.
So if TLS offers all of this, why might you want to still verify a download? The reasons are two-fold:

Not everyone might download via HTTPS. The practice of releasing a checksum together with a file predates the widespread use of HTTPS. Furthermore, the storage media you might copy your data to might be unreliable (think optical disks, etc.), and as such having a checksum already at hand that you can assume to be genuine is a good idea.

Attackers may have compromised the server. That means they could have replaced the legitimate files with malicious ones, and updated the SHA-512 checksums. However, if the releases were already signed with GPG and the GPG keys were not on the compromised webservers, everyone who would verify their download via GPG would get notified that the signature is invalid.

Do I need to do all of this?
It's up to your threat model. If you consider the chance of Apache's web servers being compromised lower than your willingness to do all of the extra steps, then just feel free to skip this step.

1 It is possible for two different inputs to generate the same output hash. In fact, since there are only 2160 different SHA-1 hashes, but there is a lot more data out there, you can be relatively sure that for any given SHA-1 hash, there are infinitely many other inputs that generate the same hash. However, finding such an input is very difficult and not feasible today.


Is it safe to use a SSH server keys for a SSH client?

Using the same private key for more than one purpose is usually a bad idea, because of the risk that you might be tricked into signing something in the first capacity, that might be used to impersonate you in the second capacity.

More precisely, is there a risk that a client connecting to your server, might trick your server into generating a signature that could be used to authenticate you to the SFTP server?

The SSH Public Key Authentication protocol does however appear to be sufficiently inconsistent with the SSH Key Agreement protocol to rule out that attack vector.

The SSH Security Considerations do not explicitly cover this question.


Is the Framekiller really safe against clickjacking?

In my opinion there's no such thing as a frame killer/buster script as JavaScript can be disabled in the <iframe tag, rendering your code useless.

The best way to protect your application from clickjacking attacks, for modern browsers, is configuring your web server to send the X-Frame-Options in the response header.

Configuring this is quite easy:

Apache
In httpd.conf add: Header always append X-Frame-Options SAMEORIGIN

Nginx
In nginx.conf add: add_header X-Frame-Options "SAMEORIGIN";


What is the ideal anonymous workstation setup?

Just some ideas:

Using a radio broadcasting device of any sort will allow signal finding to identify the source location. I would not use a cell phone regardless of its origin.
By implementing a private VPN service prior to entering the TOR network you can shift point of origin and further muddy the path.
Make sure you update Tails to get the fix to the latest compromise. This compromise is just a famous one, there are security holes detected very often. Update Tails regularly.


Is a differentially private SQL database relatively more secure from an SQL injection?

The problem with SQL injection is not how the data are stored in the database but that

statements in the query language are code and data combined into a string
these statements are often constructed by manually combining strings of code with strings of untrusted data
improper validation of the untrusted data leads to interpretation of these data as code, thus causing code-injection by an attacker

None of this is solved with using differential privacy.

It is instead solved by properly separating code from data. This can be done with parameter binding instead of manually combining code and (untrusted) data into a SQL statement string. See here for more information on this topic.


Any security risk with raising client_max_body_size nginx?

Setting client_max_body_size to 20 GB is, obviously, not reasonable and I wonder why you would allow (users?, yourself?) to upload such very huge files.

client_max_body_size governs the corresponding HTTP Header parameter. As a security good practice, we must always limit the header and message body to a minimal reasonable length. Why ? 20 GB is so huge that you put your server in the same scenario as by 2013 when Django allowed users to use a very long password forcing Django (rather the server where it is hosted) to perform very expensive hash calculations leading, as you may guess, to  a denial-of-service attack against the whole Django's authentication framework.

This is said, there are other things you need to think about if you increase too much the size of client_max_body_size. For instance, how will you set keepalive_timeout parameter ? How could you calculate it based on the fact that client_max_body_size is set to 20 GB ? May be 20 seconds ? 20 minutes ? Two hours ? Same question concerns client_header_timeout and client_body_timeout  that set, respectiely, set the maximum amount of time Nginx will wait around on the client to specify a request header or ask for an object to be served.


is there a running list that someone maintains that shows new Metasploit modules as they are released?

For that i think you want something like https://www.exploit-db.com/,

This will have a very up-to-date view of exploits recently made public, sorted by type.

New Metasploit modules will be in there as well, but that's just a small part of the exploits that are publicly released. Also using these will make the step from using just msfconsole to finding security holes yourself easier.

As mentioned, https://www.rapid7.com/db/modules/ Will have a comprehensive list of all previously released modules.


There is nothing to worry about.  The key is not sent to the router.

The key is what is used to encrypt the traffic from both ends.  So if the access point doesn't have the same key to decrypt the traffic you are sending it, all it will see is garbage.


If not user controlled, then it's not vulnerable to XSS.

Someone somewhere must be able to inject script into data to make it vulnerable.

appendTo isn't a sink in itself, however if it's appending free text to the DOM in this case then it could make the page vulnerable if data contains user input (read user input to be anything outside the security domain of the app itself).


How to secure your Mac when downloading torrents?

This assumes you are interested in ensuring the file maintains integrity in transit.

If you have access to the source files before transmit you should run a hash on the files such as sha256 or if they are large then save a litttle time using the older sha1 (depends how much you want to trust the source, md5 might be acceptable for you even)

Keep the hashes safe, when the files are received at the other end recheck the hashes.

Make sure you check at the destination before executing them though!

If you are wanting general security advice then the same rules of downloading any file apply. Such as:

Keep up to date AV
Execute with minimum privileges needed
Keep OS patched

You could also (If you think it's worth the effort) sandbox the downloads (even in its own VM) if you wanted. But I don't know what the files are for so only you will know if this level is needed.


Why did customer services say using symbols in a password is insecure?

These 'security measures' aren't for your security, but for theirs.

Symbols like hyphens, apostrophes, percent signs, asterisks, slashes, periods, etc. are useful to attackers for performing "injection" attacks, like SQL Injection, XPath Injection, file path injection, etc.  By blocking those characters, the site owners hope that they are preventing you from attacking their servers.

They should probably be focused more on proper data handling, like internally using parameterized SQL and special character escaping, but this is an additional measure that could help serve as a stopgap in case they have a hidden coding error in their site.

I can't definitively answer 'why' they did this. Maybe they had a security auditor who said "use a whitelisted character set for user input, and block any non alphanumeric symbols." Maybe the web package they bought came with that restriction. Maybe their Vice President of Security said "add some visible measures that give our customers the impression that we take security seriously." Who knows why?


This is the infamous Padding Oracle vulnerability, this is the original paper describing the vulnerability in detail.

View State related exploitation would strongly depend on the actual application logic. If the state information is properly encrypted and integrity checked the application (developer) can safely presume that the included data is trustworthy (e.g. input validation was already performed or the data originates from the server not the client). Without proper defense-in-depth measures in place this can cause a situation similar to a TOC-TOU conflict resulting in a security vulnerability.

Example: PadBuster exploits the fact that the WebResource/ScriptResource handlers presume that their parameter could only properly be set by the server and didn't check for path traversal.


What does downloading an SSL Certificate allow my school to see?

As alluded to by many of the comments on your question, the information you provided isn't enough to give a definitive answer, but here's my guess being that I am very familiar with typical campus infrastructure.

Your school likely has their own CA (certificate authority) that they use for various services on their network. Since they made the CA (and its not that widely used), your device doesn't recognize the CA and doesnt trust it. In order for your device to trust the school's CA, you need to install the certificate. Since you are required to install the CA certificate to use the wireless, my guess is your campus is using WPA2-Enterprise with RADIUS authentication using PEAP and MSCHAPv2 (pretty common). The P in PEAP stands for protected, in this case using a TLS (the new fancy term for SSL :P) to protect the communication being transferred. This does NOT give the university any direct access to your device whatsoever. This will merely allow you to connect to their network which may have monitoring ramifications (such as Deep Packet Inspection, location based on access point, Identifying your machine by the MAC address, etc) but this can occur on any netowrk regardless of the TLS certificate installation. The TLS certificate and CA install will not be adding any remote monitoring software or anything crazy like that.


No, it's an attack using algorithms such as Shor's algorithm that cannot be efficiently executed on conventional computers. A sufficiently powerful quantum computer can factor an integer in polynomial time, and many encryption algorithms rely on the difficulty of factoring large numbers.


This code is simply doing:

SHA256("12") = 6b51d431df5d7f141cbececcf79edf3dd861c3b4069f0b11661a3eefacbba918

First of all, it is using libgcrypt, something you fail to mention, and whose documentation should point you in the right path.

  gcry_md_open(&h, GCRY_MD_SHA256, GCRY_MD_FLAG_SECURE);

Create a message digest context

  gcry_md_write(h, s, strlen(s));

Add "1" to the things you are hashing

  gcry_md_write(h, s_2, strlen(s_2));

Add "2" to the things you are hashing

  x = gcry_md_read(h, GCRY_MD_SHA256);

Obtain the hash output of what was provided, ie. "1" || "2" == "12"

Also note that those strlen() work there just because you are not hashing binary data, otherwise you would get the wrong result.


In order to perform this task, you typically rely not on a single cert but on an internal certificate authority.

You first setup your own , off-line root CA and then immediately setup at least one (usually more) intermediate certificate authority with keys signed by your private root (if you're using a windows AD infrastructure, these ICAs can be setup using windows certificate services server and then integrated within you AD).

Once properly deployed (which isn't a trivial task), then you can generate and renew certificates for your servers very easily.

The weak point of this strategy is that it typically only works internally: external systems will not recognize your root as valid. A typical method of solving this is to use reverse proxy servers placed at your perimeter that will offer to external clients a certificate signed by a public root and connect to the internal systems. Since these proxies should have your private root installed, they will be able to validate your connections.

Note that this is a very high level description of the strategy: implementing it securely and globally is not easy and should be done extremely carefully.


I found the fix.

The problem was a bad network configuration of my virtual machine. When I recived this errors, the virtual machine network was configured as Bridge. When I changed from Bridge to NAT, this problem was solved.


Is someone trying to hack into my server?

It seems to me someone is trying his luck by bruteforcing for
  credentials.

Yes, that's the likely cause.  Any machine connected to the Internet and listening to SSH will be hammered with login attempts, especially for root.

  AFAIK there's no recent SSH vulnerability in public knowledge.

Correct.  They're just hoping you have a weak, guessable password.

  Why would someone run scripts to bruteforce and scan new servers? ...What would he do with a new server?

Because all servers are useful - as members of a botnet, if nothing else.  If they get in, they may use it to scan the Internet looking for weak SSH credentials!

Because some servers are valuable - hey, look, credit card info! - and the attacker doesn't know if yours is valuable or not until he owns it.  He won't ignore servers just because they might be less valuable.

Because some servers have access to other servers that aren't publicly available.

Because more is better.

The lesson to learn is that every system on the Internet is a target, all the time.  As a security student, that is what you must learn to expect.


authby=secret serve as alternative to AH in ipsec.conf

These options serve a different purpose.

authby specifies an authentication method that is used during IKE. secret sets it to pre-shared keys (PSK), which need to be strong to be secure (they are otherwise vulnerable to active attackers). IKE security associations (SAs) are used to negotiate ESP or AH SAs between the two authenticated peers.

ah causes the negotiation of an Authentication Header (AH) SA, which can be used to integrity protect and authenticate actual IP traffic. However, the AH protocol does not provide confidentiality, i.e. traffic won't be encrypted, and it won't work over NATs because the addresses in the IP header are included in the Integrity Check Value (ICV).

For both confidentiality and integrity protection/authentication use the Encapsulating Security Payload (ESP), which is the default in strongSwan (specific algorithms can be configured using the esp option). It doesn't protect the outer IP header, like AH does, but it works over NATs.

Note that strongSwan does not support the combination of the two protocols, that is, the ah and esp options are mutually exclusive.


I would not disable the antivirus on this folder. If you have performance issues cleanup WinSXS.

In case of a false positive:

contact antivirus company OR
check it with an online scanner


Encode URL in link that will appear on page in plain text?

Reverse engineering what you are trying to do from the question:
You are sending an activation link to the user out of band, and are worried about interception when clicked.

Yes, we have the technology to prevent the link from being intercepted while being clicked.

It's called "HTTPS".
In other words, make sure that the activation link look like this:
https://example.com/signup?token=1235


Edit: just so I preempt comments along the lines you know nothing about how IPS works, I will stipulate that, and instead direct my answer towards the general method of inspecting HTTPS traffic.

The short is answer is you can't.

The long answer is you would have to perform MITM attacks against the connections. This can be done in cases when you only have serverside authenticated HTTPS connections if you can force all your clients to trust a certificate that is under your control. It's often used but in my opinion it is a bad security practice since usually whatever certificate you use, will have lower guarantees of safety then the ones usually trusted by browsers and users. Even if it doesn't you are adding a new point of attack.

If you do have to use the MITM attack make sure you at least check that the certificates you are getting (from the servers) are correct, applicable for the serversm trusted and not on CRL's.

One other by-product of this approach is you are most probably teaching your users questionable security practices since they will be willing to trust obviously faked certificates for servers they communicate with. Then when they go to a hotel and see the same issue they might just assume that they are doing the same thing and happily divulge all company secrets over insecure connections.


Why are CSRF vulnerabilities considered to be a problem with the web app, rather than with the browser?

Theoretically, you are right: the web could have been designed in such a way that browsers could detect and prevent these attacks. However, it was not designed that way, and there is no trivial fix that a browser can apply that doesn't break large number of existing websites.

  One simplest example: By default, disallow cross-site requests at all?

A "cross-site request", in the context of CSRF, could be as simple as "an <img> tag referencing an image hosted on another domain". Preventing such requests would break so many websites that the browser would simply be considered broken by all its users.

  It is the browser which must stop making unauthorized requests.

The request is only "unauthorised" in the sense that a particular user didn't request it. This, on the face of it, is a more promising approach: allow the request to be made, but don't let it be authenticated as the action of any particular user.

The problem here is that the vast majority of authentication used by web applications is not actually visible to the browser as authentication at all; at most, the browser knows that the server has requested that one or more opaque strings ("cookies") be returned to it on the next request.

So, browsers would need to stop sending all cookies in requests which are "cross-site", in the sense of CSRF - when requesting images and other assets for use in an HTML page served from a different domain; when submitting forms targetting a different domain; etc.

  why should different domains (this should mean: different parties) want to talk to themselves through the user?

One obvious use case is the tracking systems used by analytics and advertising services - you might argue we'd be better off if browsers did just break them, but since the world's most popular web browser right now is developed by a company that makes a large portion of its revenue from such services, this is unlikely to happen.

Sometimes, communicating between services in the browser actually enhances the user's privacy - if the only communication that can happen is on the server, both servers have to know and discuss the user's identity.

If the web had evolved with these security considerations in mind, the safe uses of CSRF-like behaviour would be implemented by other means; but even if new protocols and APIs are invented now, it is very hard to change the default behaviour of browsers without breaking a large amount of existing content.

As such, features to protect against it, however standardised, will always be opt in, so require some work by the developer of the application, to say "I'm not relying on feature X, so please disable it so it can't be abused". Things like Content Security Policy headers, and the HttpOnly and SameSite cookie options, are such opt-ins. Things like CSRF tokens in forms are ways of not relying on the user to have an up to date browser that implements all the necessary protections.


How to get myself into a censored network?

Get somebody who is living there to provide a proxy or VPN to you. Note that this may put him at risk, so be sure to explain the risks to him.
There are already projects that do this, like ONII Probe, which provides an app to test and report blocked sites. Depending on what you are building, they may even have interest in cooperating with you or providing samples.
In addition providing VPN to you may be complicated as well, when the censors suspect that the VPN is providing unlimited access to him instead of limited access to you. But the problem with most commercial VPN is that they sell IPs that are in many geoIP databases labeled for a certain country, but do not always use data centers in this country for routing your traffic. And for data centers may apply other censorship rules than for home connections.


What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

Create a session, and use the session identifier as identifier, not the user ID directly. E.g. let user send credentials, and upon successful validation, return a (short lived) session handle, that can be used in future messages.

Validate that the session exists and is active, and map it back to user server-side.

  What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Rate limit users server side. For instance, disallow sending messages to more than ten different users a minute. This will probably not bother legitimate users, but will hamper spammers efforts. Tuning of the limit may obviously be needed - and it may be an idea to raise it for trusted users, based on behavior, and lower it upon receiving reports about spam from users.


Exploit education stack-five: trouble opening shell

Ideally you would want a precise gadget, like jmp esp, not a fixed stack address and NOP sled.
Having an int 3 breakpoint \xcc in your shellcode when running it outside of gdb will terminate execution at that point and prevent your shell code from running.
I haven't done this challenge, but you didn't say that you had verified that the shell code loads correctly in memory. Sometimes the way the program handles data there are some bytes that should be avoided (bad bytes). Looking at the source code that doesn't seem like the likely cause, but its a good habit to get into.
Sometimes you may also need to shift esp away from the payload to avoid corruption.
You can step through the shellcode using gdb to ensure that the shell code does not get corrupted and that the registers are all setup correctly and you fire the syscall.


How safe is it for the client to open a Remote App?

Security is rarely ever absolute. I mean it in the sense of not being able to say "this is absolutely safe" (negative assertions are somewhat easier).

That said, YES, using the remote app increases the effort for an attacker to compromise your client machine and in that sense, it is more secure than not using a hop.

Know though, that once the attacker compromises the remote machine it is only a matter of time before they get to your client system through the RDP server. Granted, it is not going to be straight forward, but having access is the first step. Even if they don't compromise your system, your data (while you are browsing) is up for grabs.


Check out the iOS Hacker's Handbook, chapter 4, especially the (under "Downloads") downloadable material from chapter 4. It contains a meterpreter that runs on iOS 4 that could possibly be ported to newer versions -- I verified that it does work on iOS 5.

The targeted iPhone in chapter 4 is not jailbroken or otherwise modified.


The math...32 bits.

2^32 / 2 != 65535

2^32 = 4,294,967,296
4,294,967,296 / 2 = 2,147,483,648

You don't get IPSec without IP and IP defines a source and destination address in every packet. You'll always have a source/destination with each of our SAs.

That means your limit is 4,294,967,296 or 2,147,483,648 per IP address you communicate with because your software can keep track of the SA assigned to each IP.

@eddie clarified this answer in comments.

@Kasperd points out that it's possible that the limit is actually 2^32 without dividing by two. As pointed out in comments there is no requirement that the SPIs can't be the same in both directions because the receiver can see the peer IP address. So the max could be closer to 4,294,967,296.

You'll also notice that 2^32 is the entire IPv4 space, (discounting which are globally routable) and for this question, you will not run out of SPIs any time soon and I'm pretty sure other limits (memory, bandwidth, etc) will prevent you from exceeding a much smaller threshold.


Filtering safe primes for Diffie Hellman on OpenVPN

OpenSSL does filter the primes it generates and then outputs a single one.

You should just not use the -dsaparam option.

Source: manpage


How can I Instruct a browser to reject proxy MITM certificate for my website

[new answer based on improved understanding of question based on OP comments to first, now deleted, answer]

  Is there any way for my website to tell a browser to disallow a
  substitute MITM certificate like those used by corporate proxy
  servers?

There are, although they are solutions designed to prevent the damage caused by certificates that were incorrectly issued to malicious parties by a CA.  Two such solutions are HPKP and DANE.  However, these are waning in support as other, different solutions (which don't help your use case) come into play.

HTTP Public Key Pinning (HPKP) involves the server communicating which certificates are valid to the browser within the HTTP headers. It has been deprecated, however, "because of its complexity and dangerous side-effects."  But it's worth noting particularly because, pertinent to your question,

  Most browsers disable pinning for certificate chains with private root
  certificates to enable various corporate content inspection
  scanners and web debugging tools (such as mitmproxy or Fiddler).
  The RFC 7469 standard recommends disabling pinning violation reports
  for "user-defined" root certificates, where it is "acceptable" for the
  browser to disable pin validation.

In other words - there are hooks to permit Corporate MITM in HPKP, as well.

DNS-based Authentication of Named Entities (DANE) does something similar, placing information about acceptable certificates into DNS entries.  It doesn't appear to have very good browser support, however, and if the Corporate Overlords are imposing MITM at the proxy, they're also capable of blackholing the necessary DNS queries.

Newer solutions to the problem of "bogus" certificates have shifted away from the browser, and as such aren't useful for your purposes.  DNS Certification Authority Authorization (CAA) allows server admins to publish a DNS record identifying the correct CA they use; however, this is used by other CAs as a check to avoid malicious requests for certificates from someone other than the domain owner.  Browsers do not use this record to verify anything.

Likewise, Certificate Transparency (CT) requires CAs to publish the certificates they've issued, allowing subjects and third parties to look for malicious certificates.  However, this isn't something browsers use, either.

Theoretically, if you wanted to get creative and roll your own, you could use the Forge JavaScript TLS Implementation to open a TLS session from the user's browser to your server for the purposes of inspecting the certificate.  If the certificate isn't yours, there's MITM going on!  Then you could take actions on the client side (e.g., pop up a warning) or the server side (e.g., abort the login or, if already logged in, log the user out).  It might be difficult to discern the proxy the browser is configured to use, though...


Security of using a single cert/key in an OpenVPN Setup

There is no way of knowing who is connecting to your server.  There's no attribution associated.  If someone logs in and does something bad you'll have no way of knowing who it was, or narrow down where the security breach started.

Worse, you won't know if someone else steals the certificate, and accesses your server without your knowledge.  With attribution you can at least notice, "Well user2 rarely logs in at 0200".  Then you can follow up with the user, and narrow down the breach.

I guess the bottom line is: if you only have one client authentication certificate why have one at all?


Is it dangerous not to verify the signature of an id token issued by an external authorization server?

As general rule, you should validate the signature on JSON Web Tokens whenever they are used, as this is the model of security around which they are built. There is absolutely no doubt that verifying the token is a better implementation, and even if the risk is low now, having verification in place will be a better security posture to build on for the future. Another developer down the road may assume you were verifying the token and that could cause a vulnerability even if there is not one now.

Note: Some of my opinion will be controversial to people who feel security should be absolute. I'm personally of the opinion that security needs also to be practical in order to be effective. You shouldn't spend $1000 on a safe to protect a $1 chocolate bar. But conversely, if you are dealing with valuable assets like financial information or personally identifiable information, you should certainly take appropriate precautions.

Risk

It is up to you in your implementation to determine whether it is worth the risk to skip verification.

Are the fields you're retrieving for access control, or purely for informational purposes?
Do you have alternate mechanisms in place to verify the token before this system accesses it?
What are the risks involved if the token was forged? Information disclosure? Privilege escalation? Injury or loss of life? Inaccurate security log entries?

Transport Encryption

You mentioned that it is passing over the network without TLS. I presume that is on the internal network only. A lack of transport encryption on a private network is not ideal to say the least, but you'll again have to weight the risk factors of what the token is used for to decide if this is acceptable. It will also depend on whether you trust the other security controls applied on your network - which you probably shouldn't, but you could have very good network security engineers and still not being using TLS... I don't have that information.

If it is passing over the public internet without TLS you should not trust the token at all, as it may have been compromised.

Not having encryption in transit for security tokens does expose you to a whole range of threats related to spoofing, tampering, and information disclosure. IP networks route over multiple hops, and without encryption and digital signatures provided by TLS someone could - amongst other things:

intercept the request before it gets to your 3rd-party authorization service and return an entirely forged token with more privileges
intercept a valid token in transit and alter it to have more permission than it does
steal the token in transit and inject it in requests to authorize other requests

Signature Verification and Secrets

Note also that HMAC signature methods use a pre-shared key rather than a public key for verification.

In your scenario, if an attacker stole the token you are handling, it would authorize them to do whatever that token can do. But if they managed to steal the pre-shared key, they could generate an HMAC signature for a token with any identity or permission scope in your system.

That's a risk as well, so if it's not actually essential to verify the token in your given context, it may actually be a reasonable measure to keep the shared key out of play to avoid the risk of exposure for the more valuable secret. It's all a balance of risk.

Note also that this risk does not exist for public-key or certificate-based signature methods. The key needed for verification in these cases is intended to be shared publicly and there is no risk associated with storing that information.


Display Full Credit Card Number and PCI compliance

The PCI DSS permits the display of card holder data for valid business purposes - but that comes with taking on full liability and penalties if any of your customers' cards are misused for fraud. Such display puts you directly in harm's way, and from a risk avoidance viewpoint I would very strongly discourage your implementation of this function.

If you do choose to display card holder data, there are many additional rules around authentication, logging, auditing, etc., that you will need to follow. Plus, there is data you must not store and therefore cannot display, such as CVV.  Anyone using your data will be paying the maximum interchange rate for Cardholder Not Present (CNP) transactions.

At least check with your QSA to see what they will require of you before you start down this path. The cost of implementing it, plus the tremendous risk you will take on should give your upper management a lot to think about before approving a system like this.


Is this a secure data exchange scheme for a game?

First of, crypto is hard, and you shouldn't create your own.

Vulnerabilities

Your login seems to suffer from a pass the hash vulnerability. An attacker doesn't need to crack the hash to login, they can just pass the hash, and will be logged in. This defeats the purpose of hashing the password in the first place.

sha512 is not recommended for storing passwords, as it's way too fast. Use something like bcrypt instead.

HTTPS and Encryption

You say that RSA is too expensive. But generally, RSA is only used to exchange a key, which is then used with a much less expensive private key cryptosystem.

As you clarified that you do use HTTPS, it should be noted that you do already use RSA. HTTPS uses RSA or diffie hellman for key exchange and some block or stream cipher for the actual data encryption.

As you use HTTPS, you already have data confidentiality and integrity (and server authentication and optionally client authentication), there is no need for additional encryption on the application level.

Advantages of your scheme?

Your scheme doesn't really seem to serve any purpose. You already are secure from eavesdropping and data tampering via HTTPS (and your scheme wouldn't have prevented it anyways).

So your scheme doesn't seem to be about data exchange so much, as it is about authentication.

Generally, authentication is handled like this:

Login:

Client sends username and password (plain)
Server hashes password, and compares hash against hash in db
Server sends session id back

Other Requests:

Client sends session id
Server validates session id
(optional) when session state changes, server regenerates session id

Your approach is similar, but did introduce the pass the hash vulnerability, and contains a seed, which seems to be unnecessary and thus only complicates the scheme. It also regenerates the session id on each request, which isn't really needed and only seems to cause unnecessary overhead.


This level of spam is unfortunately common: I get on a some small spam-collecting test system sometimes 15.000 spam mails a day from just a single IP address.

Having SPF, DKIM and DMARC records help against misuse of your own domain as the spoofed sender of spam. But they require that SPF and DMARC first implement a hard blocking policy and that the major number of recipients actually checks for such records and blocks spoofed mails so that it gets too expensive for the spammer. Currently this is not the case.

Checking incoming mail with SPF, DKIM and DMARC on your mail server helps to reduce the volume of spam you pass through to the internal recipients. DNS based real time blacklists are also very good in fighting spam as is Greylisting. And there are various commercial providers which help you in reducing the amount of spam you get.

And of course you should not be a source of spam yourself, i.e. make sure that none of your systems is part of a spam sending botnet and that your mail server is not an open relay which accepts mail from outside and forwards these to other external addresses.


DNS leak test shows that my ISP swaps google DNS for its own

ISP can change the responses you getting from any common DNS server in the internet, unless your DNS resolver and DNS server supports DNSSEC and also the domain in question is secured via DNSSEC.

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

If you want to have all DNS requests secured, you must use either VPN or you can use DNS resolver capable of DNS encryption in conjunciont with DNS server that offers DNS encryption.

You can use something like this: https://www.opendns.com/about/innovations/dnscrypt/


Phone Number Appears to Have Been Temporarily Hijacked

1. Have any attacks like this been reported before? (can't find any)

Sim card 'hijacking' is possible, a PAC code can be used when transferring a current number to a different existing network. However, when transferring the current number to another sim card (same network), this can be a speedy process. Linus Tech Tips experienced this type of hijacking.

Although, this would involve the old sim card being deactivated, for security purposes. So this sounds less viable given what you described.

2. What else can I do to try to figure out what happened?

Samsung Galaxy S8's were shipped with Android 8.0 and above. So sandboxing was introduced by then. Review all installed apps that have SMS permissions, or any permissions that could elevate, control and make phone calls and/or read SMS.

Less likely, but your version of Android could contain an exploit, review CVEs for your Android version. Which may have provided an attack vector to access your SMS messages. With rooting an Android device, we only know because the modified kernel does not have signed code. However, if a vulnerability was identified which allowed a jailbreak, privilege escalation could occur without the user's knowledge. Although, this is merely speculation, and it's particularly unlikely you are running some type of spyware.


SIEM technology is it database friendly?

As the others have said, your question is difficult to answer.  Rich and Adrian over at Securosis have some research to address some of your questions.  I'll stop there before I give you my own biased view on the SIEM landscape.  Best you can do is to get up to speed with the niche, the basic problem these vendors are trying to solve.  Choose a handful to investigate and a couple/few to test.


Can Nessus scanner be used behind a proxy?

The proxy functionality in nessus is for traffic such as plugin updates etc.

This is not a supported feature to use a proxy server for scan-traffic, but you can route web traffic transparently to your attack-proxy.

Take a look at How do you capture ALL the traffic from an Android app?

The same method should be possible here.


Can plugins for text editors and IDEs be malicious?

Plugins affect the way that the software behaves. So, it would be possible to write a plugin to do something malicious. And it's not just IDEs or text editors, but browsers or any software that allows plugins could be affected.

You also have to define what you mean by "malicious"? Can a plugin act as a remote access trojan? Probably not, but that depends on what the core software can do and what capabilities are exposed by the core software. Can a plugin modify or delete files maliciously? Of course.


Evil twin is an attack against wireless networks, it has nothing to do with VPNs. It may be that you are asking whether an attacker could successfully masquerade as a VPN destination in order to trick the source in to thinking it is valid. The answer to this would be a qualified no. Evil twin attacks work because wireless networks generally provide no way for a connecting host to verify the authenticity of the broadcasting station, in the case of VPNs like IPSEC both sides use a shared secret or key pairs to verify each other's authenticity.

An attacker might be able to spoof an IP address and trick one side into connecting, but without the shared secret or correct key pair a VPN would never be allowed to form.


I would go for Kali Linux .

This Linux distribution is made for pentesting and security analysis. It contains a great many analysis tools, right in your main menu.

In general, I would use an Open Source OS for security-related work, because with Open Source there is public scrutiny that your tools themselves are not compromised.


OK, it sounds like you are asking for a policy, plan, and practices for secure system administration of a data center.  I have some suggestions for you:

Start with a policy. Start by thinking out your security policy.  Develop a written security policy, and gain approval from management.

Take a look at SANS's resources on security policies.  They'll give you some ideas of things that might make sense for you.

Security plan. Develop a security plan.  I suggest you start by building up an inventory of the data and systems you store, with some idea of how critical it is to the mission of your business.  This will help you, because you should plan to devote the most energy to securing your most mission-critical assets.

Next, you might give a little thought to what are the most important kinds of attacks or threats that should receive the highest priority (either the most likely, given your situation, or the ones that would be most serious).  You can brainstorm what threats you are most likely to face (e.g., who will have an incentive to attack you?), and use this to help you develop a plan for securing your organization.

Once you have inventoried your assets and prioritized the top security issues you are likely to face, develop a plan to mitigate the risks and protect your organization from these attacks.  Take a look at the SANS list of top 20 security controls; they might form some elements of your plan, or might give you ideas for how you can protect your assets from these threats.

Execute. Next, implement your plan.  You don't need to do everything at once; it is fine to pick a piece of your plan, execute on it, and gradually grow your security maturity level.
Security training. It might be helpful to have some training on good security practices for system administrators.  I'm not the right person to ask, but others might have some suggestions.  I think SANS has a good reputation for professional training in this area.

Resources for additional information.  Take a look at Security policy for system administrators on this site.

You might want to take a look at the questions tagged security on ServerFault.  ServerFault is a sister site where many professional system administrators hang out, and they have some good resources on topics related to security oriented for sysadmins.

You should be aware of professional organizations in this area, and consider joining them and making use of their resources.  Look at SANS.  They have many resources available on their web page.

Also, look into LISA, a Usenix professional association for system administrators.  They have excellent conferences, good networking opportunities, and chances to keep up-to-date on the latest technology.  Also, they have a booklet series with some information for sysadmins; see, e.g., System Security: A Management Perspective.

What about Microsoft SDL? Microsoft's SDL is fantastic -- but it is really oriented at software development.  I don't think it's going to be as useful to system administrators, so it might not be quite the right resource for you.


Can't log in into Twitter for Android app after SSL Bypass

Ok so it turns out everything worked fine I just got IP blocked. Turned on a VPN and there are no issues.


What is described in your question is mutual authentication - two parties authenticate to each other - which is sometimes known as a 3 way handshake.

3 way authentication is typically where two parties trust a third to carry out the authentication, eg when using Kerberos both parties implicitly trust the Kerberos server. In a typical network these two parties would often be the user and the application server they want to connect to, and Kerberos authenticates the two to each other.

Kerberos is just one example - it is fairly common, but maybe the term isn't in common usage.


How does streaming and downloading work on Zero Knowledge-based cloud storage services?

Or does mega.nz store the information required to decrypt the content in the link itself? For instance, decryption key is a part of the download link?

Exactly. You can notice that their link contain a hash and a bunch of characters. Anything after the # is not sent to the web server in the petition (that's supposed to contain the anchor to which the client browser should jump). The encryption key is provided to the other party in that section of the link there. The browser javascript is able to access that part of the url and decrypt it completely client side (note that as the javascript is also provided by the cloud storage, they could use a "malicious" javascript to leak it to them).

I wonder if there is a way to actually verify that these cloud storage services which claim to use zero knowledge encryption are indeed using it?

You could use a third-party program to operate with their service. If they are following their documented api and encrypting locally the file contents, then the service supports not knowing the contents of the file (this doesn't mean it won't leak them otherwise, but it's possible). Quoting from an old megatools changelog entry:

Megareg tool is now implemented, and can be used to register new
accounts without the need for Mega website. Unless you login to
Mega, Mega will never be able to get your password key.

Generally, local clients or web extensions are safer than the site javascript, as that one is under complete control of the website. If you are a trusted client which only shares with the service files encrypted locally (in a safe way, etc.). then you can be sure they won't be able to access your files.
(Note that they might gain that ability once you provide them your password through their web interface!)
Additionally, for your peace of mind, you could always encrypt a file locally before uploading to a cloud ervice, even if it's one which supposedly encrypts the file itself in a way that the service is unable to access them.


Risks of deploying MIRAI on my local network for testing?

Releasing known malware just doesn't seem like a good idea.  A botnet's whole purpose is to engage massive numbers of devices in a coordinated attack - generally the perpetrators don't want it known that they're there and purposefully wrecking devices in the botnet keeps it small, reducing its usefulness.  I'd be more worried about my screwing up and having my devices part of a public botnet than damage to them.

If you're going to insist on doing that, there are a couple things I would make sure I do:

Ensure that the entire network is air-gapped, including wireless
Prevent any use of USB devices on any device there
If you're going to insist on using USB drives, restrict their use to your air-gapped network
Turn off wireless and bluetooth on all devices to prevent their accidental connection to other devices
Reimage everything when done with whatever is going on


Establishing a Reputable Pseudonym with PGP Key

The challenge with pseudonymous keys isn't only about anonymity; there is the additional problem of your identity being non-unique and harder to prove. Considering your pseudonym/nickname as established (that is, you are using an existing identity, rather than making up a new identity based on a hash or something among these lines), your nickname alone is not enough in asserting your identity and reputation.

If your nickname is Sam, if your friend's nickname is Sam, and if both of you have a "trusted" pseudonymous key, then neither of you can shout at the other and tell him, "hey, you're not the real Sam!"

One solution would be to regroup all information about your online identities in some unique place (where you tell "I am Sam on StackExchange", "I own the samlanning.com domain and website", and so on), and then get several people to verify and confirm all these identities. I can think of two ways of doing that:

Join a website such as Keybase (or make/host your own), which does exactly what I described, and is based on OpenPGP. Although internal, all those "central unique identities" make a web of trust, for identities/pseudonyms. A profile looks like this (yes, even the main author of GnuPG uses this website).
Using OpenPGP (and especially GnuPG), find people who are willing to sign (certify) pseudonymous keys, comply with their personal way of verifying your pseudonymous identity, and request them to incorporate policy URLs and notation data in their certifications.

I personally do this when I certify other people's keys:

gpg --ask-cert-level \
     --cert-policy-url http://diti.me/pgp/\#policy \
     --cert-notation CD42FF00@diti.me=http://diti.me/pgp/certs/%f.notes.asc \
     --sign-key

A policy URL is an URL (here, Internet document) inside of which you describe to the world what your OpenPGP key certification policy is. The person signing your pseudonymous key should tell (in this document) that they actually certify pseudonymous keys, and how.

A key notation is arbitrary text of the form key=value. The OpenPGP specification doesn't actually specify what uses should implementations make of these, but one use for them is to put an URL as the value. But you may simply have the signer put some text like "I carefully checked Sam's pseudonymous identity" if you want.

Using my command above, you can see that, on keyservers, both policy URLs and notation data are displayed by default:

sig  sig1  CD42FF00 2014-04-07 __________ __________ []
    Policy URL: http://diti.me/pgp/#policy
    Notation data: CD42FF00@diti.me http://diti.me/pgp/certs/A31D4F81EF4EBD07B456FA04D2BB0D0165D0FD58.notes.asc

For the record, this is me signing CAcert.org's automated GPG signing key, and I'll leave here a Web Archive link to the notation data.

For as long as the notation data produced by the signer can be read, anyone can/may decide whether or not they trust your pseudonymous identity. Using these, any motivated person willing to carefully check how reputable and trustable your pseudonym is, can actually do so.

EDIT: Actually, I think I might have gone a little off-topic in point 2. Is your question only about the pseudonymous certification process, or also its auditing?


Should Hashes of Sensitive Data be Encrypted

Generally speaking, no, it is not as secure.

One specific security property you lose is that of indistinguishably. What indistinguishably gives you is the ability to prevent an attacker from determining when two ciphertexts are the same message, or different messages. In order to provide this, modern encryption methods generally provide a way for you to encrypt the same message twice, or any number of arbitrary times, and end up with completely unrelated ciphertexts each time.

If you also hash the plaintext, you lose this, as the hash value will always be identical for identical messages.

Depending on the specific application, there are other security issues you could run into, up to and including the potential for complete recoverability of the plaintext from the hash values alone, but the loss of indistingishability is a certain effect.


Is Port Forwarding for bit torrent risky?

Port-forwarding means that when a connection is attempted on a specific port on your router, that connection will be forwarded to you (a machine behind the NAT) on that specific port (or, depending on the setup, it can be a different port, but let's not get into that).

Is it risky? Well, it can be risky. It all depends on the application listening on that port. In this case, the application is your BitTorrent client. There are two factors here:

Your trust in the BitTorrent client: You trust that the BitTorrent isn't actually opening a backdoor to your machine.
How up to date you're keeping your BitTorrent client: Outdated clients can have certain upatched vulnerabilities with publicly available exploits.

If you have those two points in check and you think you'll benefit from opening port (I don't think your speed will increase), then go ahead and forward that port.


Protecting code injection via chattr on php files?

The only reason I can think of is that it makes applying updates painful. However of the server is not running suphp and you apply correct file permission the apache user should not be able to overwrite these files. I've seen attacks like this using stolen ftp credentials so make sure you change those too.


Secure way to encrypt (not hash) passwords?

Depending on what other services/systems your service/system wants to log into, you probably want to store an authentication token rather than the user's password. Look into whether you can use e.g. OAuth or similar to access those other systems.


Prevent and/or detect installation of root certificates on Windows?

Windows Environments.

Background

Windows servers that have internet connectivity reach out to CA servers and automatically update Trusted Root Authority certs, CTL, STL and Revoked certificates. This occurs in the background and requires zero input or interaction from the user.

Why control it?

Many government environments like to shut this setting off as it's all about control. For instance when the Dell's eDellRoot CA certificate was first shown to be a vulnerability - Microsoft didn't revoke it right away. It took a few days before it ended up on any Untrusted or Revoked list. So many in the security field feel as though they can react faster by controlling the lists themselves. Many reduce the threat as soon as they find out through various channels as opposed to waiting for Microsoft teams deeming something unsafe.

How to control it?

To turn off Automatic Root Certificates Update via Local Group Policy Editor:

Click Start, and then click Run.
Type gpedit.msc, and then click OK.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
Under computer configuration, Double-click Administrative Templates, double-click System, double-click Internet Communication Management, and then click Internet Communication settings.
Double-click Turn off Automatic Root Certificates Update, click Enabled, and then click OK.
Close the Local Group Policy Editor.

Note that doing it this way is safer than turning off Automatic Updates. Because you still want other security patches to be applied. (Assuming you have an internet connection.)


A few files on a domain controller were encrypted - how could that have happened?

It seems ransomware itself, or the person who planted it, removed traces.

How this could happen? I think he gained himself access to it using stolen credentials, and if there's ransom note on the server, I don't think it would be clean, I think it may have some sort of backdoor, which means, it would have to be rebuilt and all passwords re-set.


is it possible to include hash (for example SHA-256) of document it the document

No. It is a problem akin to that of the self-enumerating pangram, but since the hash function is not reversible, the only way of doing this is by brute force. Given the size of the key space, this is unfeasible.


How to detect a string in HTML with Snort?

Try this

alert tcp any any <> any any (msg:"cell"; content:"7038685658"; sid:9000001;http_client_body; )

Make sure you are not loading a cached copy in the browser.


Why are hand-written signatures still so commonly used?

It pays to investigate what we really trust in hand-written signatures.

A signature is the physical manifestation of the will of the signer to acknowledge the contents of what is signed. Most legal systems define that a signature is yours and is binding if and only if "you really did it". This looks like a tautology, but it actually is quite profound: the hardness of forging, or even the involvement of a physical hand and pen, are not part of what defines a signature.

So what's the trick ? At the core of the trust system is the set of laws which severely punish forgery: forging an hand-written signature is an offense which can land you in jail for much more time than whatever you signed. The idea is that a hand-written signature happens "in the physical world" where it leaves many traces, in particular witnesses. The risk of being caught forging a signature makes it "not worth it". The signature medium is not really important; typing your name at the end of an email is as much binding as an ink-based handcrafted smudge at the bottom of a piece of paper (at least in England; there are variations depending on the country). In Japan they use personalized stamps.

The system works as long as forging signatures remains risky. When translating into the digital world, signatures become too easy to forge without any trace, which is why cryptography must be invoked. Cryptographic signatures also open the possibility of automation: being able to sign and verify at lightning speed (the verifying part is a novelty: with hand-written signatures, verification that the signature is legit is not a power given to just anybody).

The hard part of designing a signature scheme remains the set of laws which make the link between the action of signing, and the legal consequences thereof (namely, the "binding" part). Technicalities such as length of a RSA key are the easy part, which can be done by mere scientists -- but laws take decades and an awful lot of negotiation. Such laws exist for hand-written signatures; actually, they have existed for thousands of years. Digital signatures will begin to compete with hand-written signatures only when legal systems will be up to it. Europe is currently trying to do that, but it takes time.


Referer restrictions are common enough that it's one of the first things an attacker will guess when trying to figure out why they entered one URL and got a different one, especially if they know the URL is supposed to work (say, because a friend sent them the link).

No, there is no way to know that an incorrect referer is the cause of the redirect, but it's easy to guess.


How to ensure a second hand computer is safe to use

Basically you cannot win against malicious firmware. For anything on the disk, you can boot up a Linux from a CD or USB stick, and proceed to carpet the disk with zeros with a subtle dd if=/dev/zero of=/dev/sda. For firmware, you are out, unless you unsolder all the Flash chips, flash them with code of your own, and solder them back -- not a realistic method, for many reasons.

One way to look at it is the price. You can avoid the issue with malicious firmware (planted by the previous owner) by the simple expedient of buying a brand new machine from Apple instead. It will be more expensive: that's the price of the extra safety. So the question becomes: how much do you value your data ?

(If Apple themselves install malicious firmware then you are doomed anyway.)


Is sending plaintext passwords to a SQL Server database a security risk?

SQL Server has the option to encrypt the connection between application and database. When you operate SQL server in an untrusted environment, it is recommended that you enable it. When you do, hashing the passwords before sending them to the database is unnecessary as long as you trust your DB administrator.

Additionally, most deployments of SQL server will have an application server in a DMZ and the SQL server on the LAN, which means you operate in a trusted environment. Unless you have a very high security standard, having no encryption wouldn't be a big security risk.


Would my USB interface be infected if I attached and immediately detached an infected USB device?

With Windows Defender, if real-time protection is enabled, files are scanned before they are accessed and executed. The scanning scope includes all files, including those on mounted removable devices such as USB drives subject to your local configuration. The files are only scanned, they are not executed. As long as they are not executed, they won't infect your Windows machine (your USB interface).

For other pen drive to "catch the virus" you would need to copy the infected file(s) or you would need to have an active malware/virus already in your Windows machine doing so. As long as your Windows machine is not infected and as long as you do not copy the infected files into the other pen drive yourself, your other pen drives won't catch the virus. The usb interface itself cannot be infected other way then by infecting your Windows machine OS or your PC installed software including your Windows usb inferface driver. Anyway this would require executing the infected file first.


What data (of or about the app) remains in the device after the app is uninstalled?

During the installation process, Android isolates apps from one another and from the system by assigning them a distinct Linux User ID (UID) for security reasons. This UID doesn't change for duration of app's lifetime on the device. The system maintains a list of UIDs in use, and assigns the next available one to the newly installed app. Device rebooting will force the system to reconstruct the UID list, so the UIDs of the uninstalled apps will be recycled and be possibly assigned to the newly installed apps. Now here lies the risk. When an app is uninstalled, the user will be deleted. Any data left behind by this app now become what one can call "parent less", because their owner no longer exists. They don't possess any harm if they remain so.

However, if they are inherited or possessed by another app, i.e., another user (UID), there will be potential security consequences if the “parent less” knows a lot about its previous parent or still possesses some privileges
of the previous parent. This problem is called data residue problem . The data residue vulnerability is particularly complicated due to the fact that the residue might take several forms. During runtime, the system may store various types of data on behalf of apps, ranging from app permissions, operation history, user configuration choices, etc. These data can be files, databases, and in-memory data structures. They may not be simply data; they can represent
privileges (such as capabilities), i.e., whoever possesses them
can gain additional power.

For example, the URI placed on Android Clipboard by an app gives recipients the capability to access that app’s private data. If an app uses Android’s credential management services, such as AccountManager or Keystore, the credentials for the user’s online accounts can become data residues after the app is uninstalled. An email app(xyz) uses AccountManager to store the credentials for all the email accounts it manages, including Microsoft Exchange, Gmail, and Yahoo Mail. After this app is uninstalled, any
malicious app can take over all its credentials stored inside AccountManager, and can successfully log into the user’s Yahoo Mail, Gmail, and Microsoft Exchange accounts.

Nature of Application Cache: may be and may not be sensitive,both.
Location: If a newly installed app with the same UID can gain the access to the
files downloaded by their previous owner. For that the default location is

  /data/data/-
  com.android.providers.downloads/cache/

You can collect all available system services using the dumpsys utility provided by the Android Debug Bridge (adb) if you want what kind of files are left behind by an individual app after uninstallation.


A method for securely sharing centrally-stored documents among a changing set of users?

As @AviD points out, "secure" is a wide term, and there are several properties which can thus be called. Here, I will concentrate on confidentiality.

So you want some people to share some documents, which must remain unreadable for people out of that group, and such that you could afterwards add or remove some people to the group. One point to note is that, conceptually, you cannot force people to become amnesiac; hence, if a member of the group could read a document at some point, then he perfectly could have kept a copy somewhere. Therefore, revoking access of a user is about not making new documents readable by that user; for old documents, this is "too late". Given that point, a possible solution looks like this:

Every document is encrypted symmetrically with a random key K (a new key for each document).
Each user has his own public and private key pair, suitable for asymmetric encryption (e.g. a RSA or El-Gamal key pair).
Every document has a header which contains the encryption of K with the public key of each user who is deemed authorized to read the document.
To revoke a user, simply stops encrypting the K of new documents with the public key of that user.
To add a user retroactively, compute the encryption of K with the public key of that user, for each old document to which access must be granted; this can be done, of course, only by another user who can access the said documents (i.e. obtain K).

The system above is precisely what OpenPGP describes (see GnuPG for an opensource implementation). This was meant for secure emailing, but it works regardless of the actual transport medium, which could be a shared storage area.

There are drawbacks in the scheme described above:

Whoever produces the document must know the list of who should be able to access the document. This is not an absolute requirement; we could imagine a setup where the document is propagated from user to user, each user adding the encrypted K for the next user.
Each document has a header which grows linearly in the number of users in the system; for reasonably secure RSA encryption (2048-bit RSA keys), that's 256 extra bytes per user. Depending on the context, the overhead can range from the utterly negligible to the ludicrously unbearable.
The list of users who can access the document can be deduced by anybody, by looking at the header of the encrypted document.
Users have public keys, which implies the usual problem of distributing public keys in a secure way -- i.e. while avoiding usurpers. If there are many users, the solution involves a Public Key Infrastructure (PKI); OpenPGP uses the kind of decentralized PKI known as "Web Of Trust". X.509 is another PKI standard, with a pyramidal, centralized structure. Both are good at managing easy cases, and bad at scaling up.

Another, very different scheme for secure document sharing, is what is done with Blu-ray discs, with the AACS copy-protection. The security model is that there is a kind of central authority, but offline; each user (a Blu-ray player) has its own symmetric key, that the central authority also knows. When the authority publishes a new document (say, a new movie), the document is symmetrically encrypted with its own symmetric key K, and that key K is made available to all players through broadcast encryption. The authority want to distribute K to N users, where N is big, while using relatively little bandwidth (N can be in the order of hundreds of millions, but there is not that much free space on a disc), being able to add new users retroactively without requiring any document-specific transmission (you cannot patch discs once they have been built and distributed), and still having the possibility to revoke specific users. The mathematical beauty of the broadcast encryption used in AACS is that it requires size only O(log N) on each disc, plus O(R) where R is the number of revoked users. New users can be added at will. The idea is that a "user" will be revoked only if it appears that a player key has been disclosed and began to be widely copied in rogue players; hopefully (that is, the Blu-ray consortium hopes it), the individual player-breaking cost will remain sufficiently high that no more than a few dozens of such keys will have to be revoked.

Broadcast encryption uses a structure of double-nested trees which would be a bit too long to describe here. See this article for details.

There apparently is some existing research on the topic of broadcast asymmetric encryption, which avoids the need for a central authority which knows all the keys. I do not know whether good, secure schemes to that effect are currently known.


Disclosing too much info over email just to close account?

The account number you have with them is used to uniquely identify your account with them. This would have been necessary to correctly identify the account to close, so it's perfectly reasonable to request this number. Closing the correct account would be impossible otherwise.

Account holder name isn't usually considered a high value secret. If you were already a customer with them, it's likely the rep would be able to view your name if they have your account number, just so they can call you with the correct name.

The four digits of Social security number does represent a security risk to disclose to a random rep. Due to the way social security number is assigned before SSN randomization in 2011, a moderately advanced attacker has a 44% chance of guessing the first 5 digits of your SSN in a single guess, with just publicly available data, if they know where you were born (which is likely the same as your current address), and your date of birth. The last four digit are the part of SSN that is the hardest to guess since they're just serial number.

I would say that if they are only asking these for questions, they are authenticating you insufficiently.


In theory, yes.  Wifi encryption (if present), only protects data sent from your PC to their access point.  After this it is sent without additional encryption so messages could be read and captured if the Wifi owner really wanted to do that.  In practice, even capturing unencrypted data and reading it requires a higher level skill, beyond the regular systems administration skillset.  If you're a spy or access personal banking information you should worry about it and avoid using untrusted Wifi without additional encryption like a VPN.  If you are just posting social messages, chances are no one wants to try hard enough to read them.

In addition to possible Wifi encryption, your applications could be encrypting your login, password, and the data as well.  For example using an HTTPS browser URL means the data is encrypted between your PC and the system that serves the page, regardless if Wifi provides any protection.  Encrypted data can be captured but not read, in most cases.  If the URL starts with HTTP then there is no encryption and Wifi owner could eavesdrop on your messages.  On top of that, DNS queries which reveal which sites you visit will be visible.

Wifi Encryption relevance:
WEP: extremely easy to crack
WPA: easy to crack
WPA2: cracked in 2017 but patched Access Points should prevent most of the risk.

When applications don't use the browser the question is harder to answer.  You should research if your non-browser applications encrypt credentials and data and then you will know if Wifi owner has any means to capture and read your messages.


Determining the target address in a heap overflow

A great, in-depth resource on a buffer overflow attack is the Smashing the Stack tutorial by Aleph One.  While stack overflow and heap overflow are subtly different, the techniques are similar/related.

Felix "FX" Lindner writes an excellent article (2006) on The H Security which describes your exploit in depth. Condensed version below; strongly recommend the full article for clarity.

In answer to Q1, determining the exact address pointer for the stack is the catch. Often - because of stack allocation, varying program and data length, etc, you can't detect the exact position without significant knowledge of the memory layout .  Instead, a common technique is to pad a series of instructions around the payload code in an attempt to "hit" the stack pointer.  A series of NOP instructions are written before the payload code so that "if" the SP is caught in the resulting buffer overflow, the SP will advance until it runs your payload. For the case where the SP is "after" your payload code, you might write a series of JMP instructions all pointing to the head of the payload. (See the tutorial; Aleph covers this process in detail).

The goal of this heap overflow is to corrupt heap record metadata just prior to the 'write' operation implicit in the assignment of hdr->next->prev to hdr->next->next->prev. With the linked list corrupted, it is possible to overwrite the return address used by the end of free on the stack.

In answer to Q2, I'll assume you're asking about the GNU Libc implementation of free().  Other implementations will likely have different code.  Multiple sanity checks now exist to prevent invalid sized objects and double free, etc. (See the _int_free() and related functions in Git). This is not to say (definitively) the vector is impossible through other means, but it is more difficult now.

A third (draft?) source of information on this subject is a whitepaper by Justin Ferguson: Understanding the Heap by Breaking It


How is it possible to bypass single-site restriction set by ISP?

Not sure where you are getting the part about the ISP from? That isn't shown in the video as far as I can see.

What is happening in the video is that the OP is creating an SSH-based VPN for their mobile device. They are then using that as a tunnel to connect to a remote service.

This would allow the OP to bypass specific site restrictions placed on the mobile service - for example, in countries that don't allow access to certain websites.

However, the traffic patterns are possible for the mobile operator to detect using smart pattern analysis and may well be against the terms and conditions of use.

So to prevent that kind of bypass, you need to implement a smart filter. For example Sophos UTM.


Does exposing a session ID create security risks?

Does exposing a session ID create a security risk?

Not necessarily. You're exposing session id's to the browser whenever you store a session id in a cookie. This is how sessions work - the browser needs to know the session id in order to send it back to the server. The question is how you're exposing your session id. If you're sending it in cookies, that's fine - everybody does that. It's a bigger risk if you're sending the session ID as an URL parameter in a GET request (like you do when you use your image solution), because the session ID can end up in various places which you didn't expect (proxy logs, server logs, browser history etc).

  I'm looking to make a cross-domain + single app login, since you can't store cookies on other domains from one website, I'm using img tags with a href link to each website (eg: example.com/setsessionid?id=XXXX)

There's another way to do it (look into how the OAuth protocol works) which involves some clever HTTP redirects and basically works like this:

Build your login page which does authentication. Have it accept a client identifier and a sufficiently long random nonce.
Each of your other domains redirect to that login page when a user wants to login, using their client id and a random nonce, which they must store.
The login service lets the user login, and when username and password are correct, it redirects back to a "successfully-logged-in"-url on the client domain. The login service knows where to redirect to because the client domain passed the client id, which you can use to look up where to redirect to. The login service sends a few parameters along, such as the user id of the user that logged in and the (unchanged) random nonce.
The "successfully logged in"-url back on the client domain must accept and check the random nonce that was originally sent. If the nonces don't match, it must not accept the request. Otherwise, it can assume the login service correctly authenticated the user and can create an authenticated session cookie for it's own domain.

Depending on whether or not you want to provide single sign on, the login service can set it's own authentication cookie so that when the second domain redirects to the login page, the cookie is sent along and the login service can redirect to the success url immediately without asking for username and password.

This is extensible - e.g. it also works when you decouple the login service from the rest of your system and move it to a cloud service in Honolulu. And once you've built it, you can use it to let any web application authenticate using your user database, no matter where it's hosted - just add a new client id and redirect url to your login service.

You can also make it more secure by having the login service talk with the client domain directly, for example to have the client domain authenticate itself to the login service (e.g. not through the user's browser, but server-to-server) in addition to passing the random nonce - in your case, this is really easy since the login service and all the other services are hosted on the same machine, so you can simply set some flags in the database backend or create a file in the filesystem.

Also note that the system I described is only secure if the login service is reachable over https, because otherwise a MITM can simply steal the random nonce and use it to authenticate himself. But obviously thats a smart thing to do anyway, because if you don't encrypt the login page, a MITM can also just read the username and password the user sends in the clear.


Here are a few common reasons:

Certificate cost. Certificates typically are not free, and for small or otherwise less-important domains, the cost is not justified.
Virtual Hosting. While technology exists to specify a hostname during SSL negotiation, that technology is not widely enough deployed. As such, SSL domains require their own unique IP/port combination for disambiguation. And there aren't enough IPs to go around.
Caching. Edge-caching and content-distribution networks don't typically play well with SSL. This is more frequently true for third-party CDNs and proxy-based caching.


Windows mandatory access control: How to remove “mandatory level” label from the file?

I  found this tool:

http://www.minasi.com/apps/

chml filename -rl

remove mandatory level


What is the meaning of similar JA3 in many APK malware analysis reports?

JA3 is a fingerprint of the TLS stack of the TLS client and its specific configuration based on the ClientHello. As can be seen from this list the same JA3 fingerprint does not necessarily mean the same software or author. It might be for example possible that multiple authors use a specific TLS stack in the default configuration. But, a specific JA3 might nevertheless be used as a possible indicator of compromise, especially if this fingerprint is different from other (known good) programs in the same network.


Can Exchange/OWA still compress static images and be immune to HTTP compression attacks?

The recent compression-related attacks all work on the same principle: some chunk of bytes is compressed, containing both a data element that the attacker chooses, and a data element that the attacker wants to uncover. The resulting compressed length is used as a binary oracle in successive "guesses" from the attacker, who progressively rebuilds the secret value, one byte at a time.

This cannot work with static pages, because static pages are static. By definition, this means that their contents does not change often (i.e. never except by explicit action of the site administrator), and, in particular, the attacker does not get to put his own data in them.

It can be pointed out that compression is a matter of performance and, as such, is not warranted until performance problems have been duly noticed. I suggest that you first deactivate compression altogether, and see if this works well for you. If, and only if, you notice excessive network consumption or latency, does it become relevant to try higher compression levels.


Generating a GPG key with a expiration date

when i type gpg2 --full-gen-key, right after selecting the algo and keysize, i get this prompt:

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
Key is valid for? (0)

This configures the validity of your primary key. Is this what you're after?

Edit: the "expires:0" is perfectly normal for every GPG generated key, as GPG simply does not use this field for setting an expiration. This is done in the self-signature; the internal proof that the user ID provided is valid for the given public key. This is done for flexibility reasons as described here: https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/


Can anybody recommend any gems for checking security vulnerabilities?

Yes.  You want Brakeman, a tool that scans your RoR code for security vulnerabilities

I recommend reading the OWASP Ruby on Rails Security Guide.

You could also try any web pen-testing tool; they are not language-specific.  There are many of them.  They only find low-hanging fruit, not all security problems, but it can't hurt to use them just in case they find anything your other methods missed.  Search on this forum to find more information, e.g.,
What tools are available to assess the security of a web application?.