Jump to content

SirGod

Moderators
  • Content count

    695
  • Joined

  • Last visited

  • Days Won

    8

SirGod last won the day on October 1

SirGod had the most liked content!

Community Reputation

349 Excellent

1 Follower

About SirGod

  • Rank
    V.I.P.
  • Birthday 06/26/91

Converted

  • Location
    Bucuresti
  1. Urgent

    Oferă mai multe detalii sau ajunge la gunoi.
  2. Salut, Cautam un Junior Penetration Tester/Ethical Hacker pentru a se alatura echipei noastre in Bucuresti. Daca vreti sa lucrati in echipa cu 3 membri RST ( @TheTime, @dancezar si eu), trimiteti-mi CV-ul prin PM. Pentru alte detalii (non-confidentiale) astept PM. Un profil oficial (general) al job-ului ar fi urmatorul: Job Brief We are looking for a Junior Penetration Tester to join our Penetration Testing team and work in our Lab in Bucharest. Responsibilities • Identify security vulnerabilities in web applications (e.g. Internet Banking web applications, e-commerce websites, web portals) • Conduct internal network penetration testing - simulate a malicious individual (e.g. guest, temporary personnel) who already has access to our client's internal network of our client. Starting only from a simple network port access, you should gain access to sensitive information from the client's internal network, gain Domain Admin access or reach other flags • Perform mobile application penetration tests on Android, iOS, or Windows applications • Exploit the identified vulnerabilities and identify specific, meaningful risk to clients based on industry and business focus • Write comprehensive reports including assessment-based findings, outcomes and recommendations for further security enhancement Requirements • Experience in identifying and reporting security vulnerabilities • Familiarity with web related technologies (Web applications, Web Services) and of network/web related protocols • Detailed technical knowledge of at least one of: software security, operating systems security, network security • Understanding of the latest security principles, techniques and protocols • Should have excellent English written and verbal skills • Bachelor’s degree in Computer Science or related field • Problem solving skills and ability to work under pressure • Should be able to work individually or as member of a team Benefits • Attractive salary package, including meal tickets and health insurance • Work with like-minded, driven and smart team members • Encouraged to perform research and participate at security conferences • Work flexibility • Private, dedicated workspace for security related projects
  3. Bug scanner MIX/UNIX

    2017-10-10 10:42:21,086 fail2ban.actions: WARNING [ssh] Ban meteor
  4. Macro-less Code Exec in MSWord

    Da, interesant, dar metodele de exploatare (clasic si cu DDE) sunt deja cunoscute de la exploarea CSV injection (https://www.contextis.com/blog/comma-separated-vulnerabilities). Bine de stiut ca functioneaza si in Word, pacat ca si in cazul asta apar doua alerte.
  5. Link articol: https://www.peew.pw/blog/2017/10/9/new-vulnerability-same-old-tomcat-cve-2017-12615 Link exploit: https://github.com/peewpw/metasploit-framework/blob/patch-1/modules/exploits/multi/http/tomcat_jsp_upload_bypass.rb
  6. Author: Max Justicz Link: https://justi.cz/security/2017/10/07/rubygems-org-rce.html Remote Code Execution on rubygems.org Oct 7, 2017 tl;dr Remote code execution via a deserialization vulnerability on rubygems.org, a very popular hosting service for ruby dependencies. A fix was rolled out quickly. Read the official announcement here. CVE-2017-0903 If you have ever written a ruby application, it is very likely that you have interacted with rubygems.org. You’ve probably even trusted that site to run arbitrary programs on your computer. When you run, for example, gem install rails, the gem utility fetches the rails gem and all of its dependencies from rubygems.org, and installs everything into the appropriate places. Anyone can publish gems there after making an account. Rubygems.org is itself a rails application with a clearly laid out responsible disclosure policy. Vulnerability Ruby gems are actually just tar archives, so running tar -xvf foo.gem will ordinarily leave you with three files: metadata.gz data.tar.gz checksums.yaml.gz These files are pretty much what they look like. All are gzipped. metadata.gz contains a YAML file with information about the gem like its name, author, version, and so on. data.tar.gz contains another tar archive with all the source code. checksums.yaml.gz contains a YAML file with some cryptographic hashes of the gem’s contents. I was surprised to learn that parsing untrusted YAML is dangerous. I had always figured it was a benign interchange format like JSON. In fact, YAML allows for the encoding of arbitrary objects, much like python’s pickle. When you upload a gem to rubygems.org, the application calls Gem::Package.new(body).spec. The rubygems gem, where this method lives, uses unsafe calls to YAML.load to load the YAML files in the gem. However, the authors of rubygems.org knew this (probably as a result of this incident), and as of 2013 were monkey-patching the YAML and gem parsing libraries to only allow the deserialization of a whitelist of classes, eventually switching to using Psych.safe_load in 2015. Unfortunately, the monkey-patching was insufficient, since it only patched the Gem::Specification#from_yaml method. If we check out what actually happens in that call to #spec, we see that it calls #verify, the important parts of which are reproduced below: # ... @gem.with_read_io do |io| Gem::Package::TarReader.new io do |reader| read_checksums reader verify_files reader end end verify_checksums @digests, @checksums # ... Then, in #read_checksums: # ... Gem.load_yaml @checksums = gem.seek 'checksums.yaml.gz' do |entry| Zlib::GzipReader.wrap entry do |gz_io| YAML.load gz_io.read # oops end end # ... OK, so we have a call to YAML.load with input that we control. How can we exploit it? Originally I attempted to have my exploit code run at the time of the YAML.load call itself. This turned out to be more challenging than I had anticipated, because although I could deserialize arbitrary objects, the only actual method calls I could make on those objects were very limited. Psych, the YAML parsing library used here, would let me make calls to methods like #[]=, #init_with, and #marshal_load (not Marshal.load; that would have made exploitation much easier). But for most objects, those methods don’t give an attacker much flexibility, since common practice is for them to just initialize a couple variables and return. It seems plausible that there is some object in some standard rails library with a dangerous #[]= method (as there have been in the past), but I didn’t find one. Instead, I looked back at the rubygems.org application. What does it do with that @checksums variable, which we can now set to be an instance of any in-scope class? Over in #verify_checksums: # ... checksums.sort.each do |algorithm, gem_digests| gem_digests.sort.each do |file_name, gem_hexdigest| computed_digest = digests[algorithm][file_name] # ... So if we can build an object where calling #sort does something dangerous, we can trigger our exploit. In the end, I came up with the following proof of concept. The payload that actually gets evaled is contained in the base-64 encoded, DEFLATE compressed, marshalled section at the bottom (in this case, it just shells out to run echo "oops"): SHA1: !ruby/object:Gem::Package::TarReader io: !ruby/object:Gem::Package::TarReader::Entry closed: false header: 'foo' read: 0 io: !ruby/object:ActiveSupport::Cache::MemoryStore options: {} monitor: !ruby/object:ActiveSupport::Cache::Strategy::LocalCache::LocalStore registry: {} key_access: {} data: '3': !ruby/object:ActiveSupport::Cache::Entry compressed: true value: !binary '\ eJx1jrsKAjEQRbeQNT4QwQ9Q8hlTRXGL7UTFemMysIGYCZNZ0b/XYsHK8nIO\ nDtRBGbvJDzxMuRMLABHzIzOSqD0G+jbVMQmhzfLwd4jnphebwUrE0ZAoJrz\ YQpLE0PCRKGCmSnsWr3p0PW000S56G5eQ91cv9oDpScPC8YyRIG18WOMmGD7\ /1X1AV+XPlQ=' Starting from the last step and working backwards to the call to #sort: At the bottom we have an ActiveSupport::Cache::Entry object. The important thing about this object is that when the #value method is called and @compressed is true, it will call Marshal.load on DEFLATE compressed, attacker provided data. The object that is unmarshalled is constructed in such a way that calling just about any method on it will execute the attacker’s code. The exact method used here has been written about before – here is how it works. Unfortunately, we can’t just deserialize this object with YAML to achieve code execution, because it undefs almost all of its methods, including the ones that allow us to set instance variables. It really needs to be loaded with Marshal.load to be useful in this context. Working our way up, the ActiveSupport::Cache::MemoryStore object holds our malicious unmarshalled object in a hash called @data. Its parent class, ActiveSupport::Cache::Store defines a #read method that calls #read_entry within the MemoryStore. #read_entry basically just grabs the entry out of @data and returns it. The call to MemoryStore#read comes from a call to Gem::Package::TarReader::Entry#read, which itself is called by Gem::Package::TarReader#each. After the read returns, #size is called on the returned value, which our malicious unmarshalled object does not define, causing our payload to execute. Finally, because Gem::Package::TarReader specifies include Enumerable, a call to its #sortmethod will call its #each method, starting the whole chain above. Conclusion For me, one of the takeaways here is that YAML is very powerful, and sometimes used in contexts where less expressive (but safer) interchange formats like JSON might be more appropriate. Perhaps in the future, YAML.load could be modified to take a whitelist of classes as an optional parameter, making the deserialization of complex objects an opt-in behavior. YAML.load in its current state should really be named something like YAML.unsafe_load to get the point across, instead of relying on users to know when they should use YAML.safe_load. Thanks very much to the rubygems.org team for running a responsive bug bounty program.
  7. Author: Stefan Sabin Nicula Link: https://securitycafe.ro/2017/09/22/robot-hacking-research/ Summary:
  8. Link: http://www.pathname.com/fhs/pub/fhs-2.3.html Table of Contents: 1. Introduction Purpose Conventions 2. The Filesystem 3. The Root Filesystem Purpose Requirements Specific Options /bin : Essential user command binaries (for use by all users) Purpose Requirements Specific Options /boot : Static files of the boot loader Purpose Specific Options /dev : Device files Purpose Specific Options /etc : Host-specific system configuration Purpose Requirements Specific Options /etc/opt : Configuration files for /opt /etc/X11 : Configuration for the X Window System (optional) /etc/sgml : Configuration files for SGML (optional) /etc/xml : Configuration files for XML (optional) /home : User home directories (optional) Purpose Requirements /lib : Essential shared libraries and kernel modules Purpose Requirements Specific Options /lib<qual> : Alternate format essential shared libraries (optional) Purpose Requirements /media : Mount point for removeable media Purpose Specific Options /mnt : Mount point for a temporarily mounted filesystem Purpose /opt : Add-on application software packages Purpose Requirements /root : Home directory for the root user (optional) Purpose /sbin : System binaries Purpose Requirements Specific Options /srv : Data for services provided by this system Purpose /tmp : Temporary files Purpose 4. The /usr Hierarchy Purpose Requirements Specific Options /usr/X11R6 : X Window System, Version 11 Release 6 (optional) Purpose Specific Options /usr/bin : Most user commands Purpose Specific Options /usr/include : Directory for standard include files. Purpose Specific Options /usr/lib : Libraries for programming and packages Purpose Specific Options /usr/lib<qual> : Alternate format libraries (optional) Purpose /usr/local : Local hierarchy /usr/local/share /usr/sbin : Non-essential standard system binaries Purpose /usr/share : Architecture-independent data Purpose Requirements Specific Options /usr/share/dict : Word lists (optional) /usr/share/man : Manual pages /usr/share/misc : Miscellaneous architecture-independent data /usr/share/sgml : SGML data (optional) /usr/share/xml : XML data (optional) /usr/src : Source code (optional) Purpose 5. The /var Hierarchy Purpose Requirements Specific Options /var/account : Process accounting logs (optional) Purpose /var/cache : Application cache data Purpose Specific Options /var/cache/fonts : Locally-generated fonts (optional) /var/cache/man : Locally-formatted manual pages (optional) /var/crash : System crash dumps (optional) Purpose /var/games : Variable game data (optional) Purpose /var/lib : Variable state information Purpose Requirements Specific Options /var/lib/<editor> : Editor backup files and state (optional) /var/lib/hwclock : State directory for hwclock (optional) /var/lib/misc : Miscellaneous variable data /var/lock : Lock files Purpose /var/log : Log files and directories Purpose Specific Options /var/mail : User mailbox files (optional) Purpose /var/opt : Variable data for /opt Purpose /var/run : Run-time variable data Purpose Requirements /var/spool : Application spool data Purpose Specific Options /var/spool/lpd : Line-printer daemon print queues (optional) /var/spool/rwho : Rwhod files (optional) /var/tmp : Temporary files preserved between system reboots Purpose /var/yp : Network Information Service (NIS) database files (optional) Purpose 6. Operating System Specific Annex Linux / : Root directory /bin : Essential user command binaries (for use by all users) /dev : Devices and special files /etc : Host-specific system configuration /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) /proc : Kernel and process information virtual filesystem /sbin : Essential system binaries /usr/include : Header files included by C programs /usr/src : Source code /var/spool/cron : cron and at jobs 7. Appendix The FHS mailing list Background of the FHS General Guidelines Scope Acknowledgments Contributors
  9. Snuffleupagus - PHP 7 security module

    Da, nu e mare branza. Totusi ca si modul de PHP nu prea pot face ceva solutie generala si eficienta. Nu e facut sa fie folosit enterprise sau oricine altcineva care vrea securitate. Eu ii vad locul pe ceva siteuri mici care nu isi permit sa angajeze developeri sau sa faca pentest si vor ceva rapid, usor de instalat si ce ofera un oarece sentiment (fals) de securitate.
  10. Snuffleupagus is a PHP 7+ module designed to drastically raising the cost of attacks against website, by killing entire bug classes, and also providing a powerful virtual-patching system, allowing administrator to fix specific vulnerabilities and audit suspicious behaviours without having to touch the PHP code. Snuffleupagus has a lot of features that can be divided in two main categories: bug-classes killers and virtual-patching. The first category provides primitives to kill various bug families (like arbitrary code execution via unserialize for example) or rise the cost of exploitation, the second one is a highly configurable system to patch functions in php itself. Link: https://snuffleupagus.readthedocs.io/
  11. Brutus FTP Attack Tool 0.3

    Python, indentare. Posibil sa se piarda spatiile/tab-urile pe la copy/paste.
  12. kernel-exploits

    Pe aceeasi tema, lista exploituri de Linux Kernel (privilege escalation): https://github.com/lucyoa/kernel-exploits Aveti versiunile de Kernel vulnerabile pentru fiecare exploit in parte. In plus aveti si varianta deja compilata pentru o parte din ele (daca aveti incredere si nu mai vreti sa pierdeti timpul cu compilation flags si instalari de biblioteci).
  13. Intrebare legata de WIFI

    Penibil.
  14. Cateva trucuri interesante pentru CSS Injection. Article: https://reactarmory.com/answers/how-can-i-use-css-in-js-securely Author: James K Nelson Summary: Exploiting CSS-in-JS CSS-in-JS tools are like eval for CSS. They’ll take any input and evaluate it as CSS. The problem is that they’ll literally evaluate any input, even if it is untrusted. And to make matters worse, they encourageuntrusted input, by allowing you to pass in variables via props. If your styled components have props whose value is set by your users, you’ll need to manually sanitize the inputs. Otherwise malicious users will be able to inject arbitrary styles into other user’s pages. But styles are just styles, right? They can’t be that scary…
×